info-tech-canon/infospace/patterns/PracticePatternScheme.md

id	title	type	status	version	summary	owned_concepts
scheme/practice-pattern	PracticePattern Scheme	practice-pattern-scheme	active	0.1	A common Markdown contract for naming and sharing recurring socio-technical practices.	PracticePattern PatternLanguage

PracticePattern Scheme

Intent

Give people and agents a stable language for recurring ways of working. A PracticePattern names a proven or proposed arrangement of actions, roles, interfaces, feedback, and evidence that resolves a recurring tension in a particular context.

This scheme is inspired by Christopher Alexander's pattern-language method: each pattern connects a context and a system of forces to a reusable solution, describes the resulting consequences, and participates in a language of related patterns. It adapts that idea for software, operations, architecture, and governance practices; it does not copy a building pattern or require a fixed implementation technology.

Artifact identity

A PracticePattern is a Markdown canon artifact with:

• a speakable canonical name in UpperCamelCase, such as InterfaceDeprecationStrangler;
• a stable artifact ID, practice-pattern/<kebab-case-name>;
• type: practice-pattern;
• scheme: practice-pattern/0.1;
• an independently versioned pattern body;
• a lifecycle status; and
• registration in infospace/artifacts/index.yaml.

The canonical name is part of the shared language. Aliases help discovery but must not silently replace it.

Required frontmatter

---
id: practice-pattern/example-name
title: ExampleName
type: practice-pattern
scheme: practice-pattern/0.1
status: candidate
version: "0.1"
summary: One sentence stating the practical move.
aliases: []
uses: []
related_patterns: []
known_uses: []
---

The machine-readable contract is infospace/schemas/practice-pattern.schema.yaml.

Lifecycle

Status	Meaning
draft	The problem and solution are still being shaped.
candidate	Coherent enough for trial, but known uses are limited.
active	Supported by at least one concrete known use and suitable for reuse.
deprecated	Superseded or discouraged; relationship to its successor is explicit.
retired	Preserved for provenance but no longer recommended.

Version and lifecycle are separate. A wording clarification can change the version without changing lifecycle; evidence from a new known use can promote a candidate to active.

Required body sections

Every PracticePattern must contain these second-level headings:

1. Intent — the practical move in compact form.
2. Context — the conditions in which the pattern applies.
3. Problem — the recurring failure or tension.
4. Forces — pressures that make a simplistic solution insufficient.
5. Solution — the stable arrangement, written as a directive.
6. Dynamics — the sequence or feedback loop through which it operates.
7. Invariants — properties an implementation must preserve.
8. Evidence — observations needed to decide, advance, or stop.
9. Consequences — benefits, costs, and new responsibilities.
10. Known Uses — concrete applications and their maturity.

These headings are validated by the canon. Their contents may use diagrams, tables, checklists, or prose.

Recommended body sections

Use these where they improve adoption:

• Structure for roles, components, and relationships;
• Failure Modes for common incomplete or unsafe implementations;
• When Not to Use for boundary conditions;
• Adoption Checklist for a practical start and completion test;
• Related Patterns for the surrounding pattern language; and
• Evolution for provenance, open questions, and version history.

Writing rules

1. Name a recurring practice, not a product feature or one repository's implementation.
2. State the problem before prescribing the solution.
3. Make forces genuinely competing; a list of requirements is not a force analysis.
4. Write the solution as a stable arrangement and keep technology-specific examples in Known Uses.
5. Separate invariants from optional implementation techniques.
6. State which evidence changes the practice's state or permits an irreversible move.
7. Name costs and failure modes as directly as benefits.
8. A known use must identify what was actually observed; intended adoption is not implementation evidence.
9. Relationships must use stable artifact IDs when the related artifact is in the canon.
10. Pattern conformance means preserving the invariants, not copying a known use literally.

Relationship vocabulary

PracticePatterns form a language rather than an isolated catalog. Use:

• uses when this pattern depends on another canon artifact or mechanism;
• related_patterns for complementary, alternative, predecessor, or successor PracticePatterns, with the relation explained in the body;
• artifact-index conforms_to to point to this scheme;
• artifact-index uses, requires, or implements for graph-visible canon relationships; and
• Known Uses to point outward to concrete consumer implementations.

Conformance

A file conforms to PracticePattern v0.1 when its frontmatter validates against the schema, all required body sections are present, its artifact index entry has kind: practice-pattern, and every internal relationship target resolves.

Conformance does not imply that the practice is active or recommended. That is expressed by lifecycle status and known-use evidence.

Evolution

Version 0.1 establishes the smallest useful shared contract. Later versions may add structured force, role, evidence, and known-use records after several patterns demonstrate which structure is genuinely reusable.