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

---
id: scheme/practice-pattern
title: PracticePattern Scheme
type: practice-pattern-scheme
status: active
version: "0.1"
summary: A common Markdown contract for naming and sharing recurring socio-technical practices.
owned_concepts:
  - 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

```yaml
---
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.