← PATTERNS

Formalise Capture

Symbolic structure inscribed for inspection — versioned, not yet adopted

Core principle

Versioned symbolic structure is formalise on the log — inspectable and diffable — until an explicit commit adopts that version as authoritative.

Formalise capture is tier-one evidence where symbolic structure is inscribed for shared inspection — definitions, schemas, policies, process specs, proof steps — not yet organisational truth. It answers: was structure versioned on the log for review?

The normative artifact ladder

Rules, values, governance, processes, and software contracts rarely jump from brainstorm to bind. The corpus uses a three-step ladder:

assert (draft) → formalise (inscribed vN) → ValuesAdopted / PolicyAdopted / SchemaAdopted (bound to vN)
                      ↓ later
              formalise (vN+1) → DecisionSuperseded (vN stays; vN+1 authoritative)
StageCapture modeWhat it isBinding?Example events
Draft / sketchassertConjecture, candidate, loose proposalNoHypothesisLogged, draft assert, narrative policy sketch
Inscribed vNformaliseVersioned structure on the log (contentHash, version, supersedesVersion)NoFormalisationInscribed, PolicyInscribed, SchemaInscribed
AdoptedcommitOrganisation binds to that versionYesValuesAdopted, PolicyAdopted, SchemaAdopted, TheoremAdopted

Discriminator: Loose forward → assert. Versioned artifact ready for adoption ceremony → formalise. “This version is now authoritative for us” → commit (with ref to the formalise event id).

Prior inscriptions stay append-only; supersession and retraction are commits, not silent edits — When Facts Are Wrong.

Event shape

type: FormalisationInscribed   # or domain-specific Formalise type
schemaVersion: 1
inscribedBy: string
formaliseKind: definition | schema | proof_step | translation_map | ...
name: string
version: string
contentHash: string
supersedesVersion: string | null
formalisationRef: { eventId: string } | null   # prior formalise, if any

Adoption commits reference the formalise event: formalisationRef: { eventId: "FormalisationInscribed:evt-…" }.

formaliseKind — grouped vocabulary

One formalise force; formaliseKind (or dedicated type names) distinguishes artifact class. Not exhaustive — extend as domains require.

Vocabulary & meaning

definition, glossary, translation_map, ontology_term, taxonomy

Technical structure

schema, event_type, api_contract, interface_spec, module_spec, infrastructure_spec

Governance & operations

policy, rule, regulation_mapping, process, workflow, operating_procedure

Formal / proof

proof_step, theorem_statement, axiom_set

Decision & software artifacts

adr_proposal, decision_record_draft, source_artifact

In software systems

Event schemas, OpenAPI contracts, ADR text, and pinned source hashes are formalise when logged for review; deploy or merge-to-prod decisions that adopt them are commit. Code in an IDE alone is off-log derive until inscribed or bound.

In human organisations

Policy v2.3 on the record for board review = formalise. Board vote adopting v2.3 = commit. External statute (EUR-Lex) is external T1 — internal regulation_mapping formalises how you interpret compliance before commit.

In socio-technical systems

Ethics drafts and schema proposals move assert → formalise → PolicyAdopted / SchemaAdopted with contest paths (contestability) between inscription and adoption.

Why this solves the anti-pattern

CRUD as domain language

Formalise types name inscription for inspection — not EntityUpdated. Adoption is a named commit, not an update row that hides when a rule became authoritative.