Four Capture Modes

Separating capture mode from domain type does not fix instrument error — it makes the error classifiable.

We propose four capture modes — the minimum vocabulary for tier-one honesty — and show how we stress-tested that claim. The schema is meant for event-driven architectures as much as for epistemology: a contribution to the community that cares about append-only logs, domain events, and provenance.

The problem event sourcing hides

Event-sourced systems celebrate immutable history. Every state change is an event; the log is the source of truth.

But “source of truth” smuggles in an epistemic claim the log does not automatically earn. A stored event might be:

• a binding decision (someone committed),
• a conjecture (someone proposed),
• an instrument reading (something measured),
• or a symbolic inscription (a definition, proof step, or mapping logged).

Domain language — onboarded, converted, shipped, retracted — describes what the business thinks happened. Storage verbs — created, updated, deleted — describe how persistence changed; they are not domain language and usually hide the act. Neither layer says how the record became evidence. That gap is where inference-as-fact, capture-chain distortion, CRUD as domain language, and epistemic tier collapse breed. See Domain Events Are Not CRUD.

Two layers for capture; one catalogue for stress-testing:

Effect classes — registered, retired, superseded, transferred, and the rest — are not part of how truth is captured. They are labels in the stress-test catalogue below: typical domain situations used to ask whether every case still maps to one of the four forces. Domain event type uses business verbs (CustomerOnboarded, AssetRetired) — not CRUD. See Domain Events Are Not CRUD.

OrderPlaced is a domain name. The capture force is usually commit — an authority bound a new fact.

Commit — binding

An agent or institution binds — self, organisation, or successor state — to a fact or rule. → Commit capture

Examples: signature, values adoption, governance decree, democratic outcome, ResponseSent, witness attestation, tombstone on delete (append-only retirement), merge decision at a boundary.

Failure modes: forged commitment, coerced commitment, insincere commitment, second-hand commitment.

Assert — non-binding forward

Something is put forward without binding — conjecture, draft, candidate, token emitted before send. → Assert capture

Examples: draft article, hypothesis logged for review, LLM output saved honestly as model assertion. L-β symbolic streams (inner speech, chain of thought (CoT), token traces) are assert when logged — event shapes, batching, correlation, and topology are developed in Thinking by Writing, not here.

If assert is later treated as measure or commit without a boundary crossing, the log has lied about how evidence entered.

Measure — instrument transduction

The world or a signal is transduced through an instrument chain at the capture boundary. → Measure capture

Examples: sensor reading, application programming interface (API) payload ingested as observation, hardware random number generator (RNG) output, network time protocol (NTP) offset sample, X-ray file at the picture archiving and communication system (PACS) boundary.

Human-mediated measurement. Not every measure is a digital sensor writing directly to the log. A physician reads an analog thermometer or pressure gauge, decides the needle sits closer to 39.1 than 39.2, answers the patient’s question, then writes the value in a chart — from memory, by hand. Each step is still measure (transduction), not commit (binding to act on the value), but the chain is longer and each link adds uncertainty:

The number that enters the software — 39.1 in an electronic health record — is honest about what was stored. It is not automatically honest about how that number was produced. A value captured automatically from a calibrated digital probe at the bedside is a different epistemic object from the same numeral typed after a human read an analog dial minutes earlier. Both belong in tier one as measure; both require chain metadata so downstream systems do not treat them as equally direct.

Reporting measurements therefore means reporting capture path: instrument class, calibration state, whether a human read and transcribed, manual entry vs automated ingest, and where the boundary was crossed. Without that, audit cannot distinguish instrument fault from transcription fault — and capture-chain distortion is guaranteed the moment the final field is treated as if the Real spoke directly into the database.

What goes wrong in practice. These failures rarely announce themselves with a labelled alarm. Teams notice contradictions — paper chart vs screen, partner ledger vs local log, repeat measurement that disagrees with what was recorded. They notice downstream harm — treatment based on a vitals value that was misread, mistyped, or conflated with a device-grade reading. They notice disputes — “I never said 39.1” when the field shows a numeral with no chain metadata. The linked pattern capture-chain distortion covers the general case; under measure, the recurring mistake is treating every stored number as if it arrived the same way — direct from a calibrated instrument — when the path was human eyes, memory, and keyboard.

Formalise — symbolic inscription

Symbolic structure is inscribed — definition, naming map, proof step logged, axiom stated (not yet adopted). → Formalise capture

Examples: glossary entry, ontology term, proof object in a proof assistant, translation map between symbol systems, a proposed event or API schema written for review, policy or process spec versioned on the log.

The normative artifact ladder

Rules, values, governance, processes, and software contracts use a three-step ladder before production authority attaches:

assert (draft) → formalise (inscribed vN) → ValuesAdopted / PolicyAdopted / SchemaAdopted (bound to vN)
                      ↓ later
              formalise (vN+1) → DecisionSuperseded (vN stays; vN+1 authoritative)

Discriminator: loose forward → assert; versioned artifact ready for inspection → formalise; “this version is authoritative for us” → commit (referencing the formalise event id). Full formaliseKind vocabulary and grouped kinds: Formalise capture.

Versions accumulate; a proposal may be discarded without adoption. Prior inscriptions stay append-only. Governance transitions — supersession, retraction — are commits; see When Facts Are Wrong.

Recommended event types

One envelope with captureForce and a long tail of optional fields invites omission: teams log IdentityVerified with no path metadata and call it done. Type the capture mode instead — separate event types (or fixed type families) whose schemas declare mostly or entirely required fields. Domain vocabulary stays on commit types (LoanApproved, AssetRetired); measure, assert, and formalise use their own type names so auditors never infer mode from a verb that sounds like a bind.

Every tier-one event shares a thin envelope — all required:

# Envelope (all tier-one events)
eventId: string
type: string              # names the capture family + domain act
schemaVersion: integer    # per-type contract version
occurredAt: datetime      # when the act happened at the boundary
recordedAt: datetime      # when append succeeded (audit)
correlationId: string     # one business process, case, or conversation
causationId: string       # eventId that triggered this, OR requestId of the API command
causationKind: event | request
contextRef:               # harness / MCP / session snapshot for interpreting asserts
  contextEventId: string | null   # inherited ContextAttached or prior context event
  contextHash: string             # canonical hash of tools, resources, MCP payload
  mcpSessionId: string | null     # Model Context Protocol session when applicable

Correlation groups everything that belongs to one end-to-end process — a loan file, an incident, a multi-step workflow. Causation links each append to what triggered it: the prior event in a chain, or the requestId of a command submitted via API. Context (contextRef) carries harness or MCP snapshot state so downstream events are interpreted against the same tool and resource picture — essential for L-β thought capture; see Thinking by Writing.

Below that envelope, required fields depend on the type — not on optional branches in one mega-schema.

Measure — instrument transduction

Use a measure type when the record is transduction at a boundary. capturePath is required; path-specific fields are required for that path (not nullable “if present”).

# Example: InstrumentMeasurementRecorded
type: InstrumentMeasurementRecorded
schemaVersion: 1
occurredAt: datetime
recordedAt: datetime
capturePath: instrument_direct
instrumentId: string
calibratedAt: datetime
calibrationRef: string      # certificate or policy id
quantity: string            # e.g. temperature_c, hba1c_mmol_mol
value: number | string
unit: string
boundarySystem: string      # where transduction crossed into our log

# Example: HumanTranscribedMeasurementRecorded
type: HumanTranscribedMeasurementRecorded
schemaVersion: 1
occurredAt: datetime
recordedAt: datetime
capturePath: human_transcribed
observerId: string
instrumentClass: string     # analog dial, paper chart, …
observedAt: datetime        # when human read the instrument
transcribedAt: datetime     # when value entered the log
quantity: string
value: number | string
unit: string

# Example: PartnerPayloadIngested (boundary read — not yet “ours”)
type: PartnerPayloadIngested
schemaVersion: 1
occurredAt: datetime
recordedAt: datetime
capturePath: partner_relay
sourceSystem: string
sourceEventId: string
payloadHash: string
contentType: string

Relay remains two typed events, not a fifth mode: PartnerPayloadIngested (measure at boundary) then a commit type that accepts into the corpus (see commit family below) with ingestRef pointing at the measure event id.

Assert — forward without bind

Use an assert type when material is put forward without binding. Generic conjecture and specialised pre-bind freezes are different types with different required fields.

# Example: HypothesisLogged
type: HypothesisLogged
schemaVersion: 1
occurredAt: datetime
recordedAt: datetime
assertedBy: string
claimSummary: string
relatedEventRefs: string[]  # may be empty array, never omitted

Automated and human pre-bind asserts at the commitment boundary use fixed types defined in The Moment of Commitment — ReasoningAsserted and HumanReviewAsserted — each with a closed required shape (inputs, reasoning, policy vs reviewerId, materialShown, conclusion). Commits reference them by reasoningAssertRef / humanReviewAssertRef event ids, not inline blobs.

Commit — binding

Commit types carry domain names (LoanApproved, ValuesAdopted, RecordTombstoned) and a fixed accountability surface. Required on every commit:

# Pattern — domain type varies; accountability block is fixed
type: LoanApproved              # domain verb — not CRUD
schemaVersion: 1
occurredAt: datetime
recordedAt: datetime
decidedBy: string               # authority at the boundary
decidedAt: datetime
policyVersion: string             # or policyRef: { id, version }
# Automated / human-in-the-loop — refs required when path applies:
reasoningAssertRef: { eventId: string } | null   # null only on human-only path
humanReviewAssertRef: { eventId: string } | null
# Relay accept — required when accepting partner measure:
ingestRef: { eventId: string } | null
# … domain payload (applicationId, amount, …) — all required for this type

reasoningAssertRef / humanReviewAssertRef / ingestRef are required keys on the commit schema; use explicit null when that path does not apply — so validators never silently omit accountability.

Formalise — symbolic inscription

Use a formalise type when structure is inscribed for inspection, not yet adopted.

# Example: FormalisationInscribed
type: FormalisationInscribed
schemaVersion: 1
occurredAt: datetime
recordedAt: datetime
inscribedBy: string
formaliseKind: definition | schema | proof_step | translation_map | ...   # not exhaustive — see [Formalise capture](/patterns/patterns/formalise-capture/#formalisekind--grouped-vocabulary)
name: string
version: string
contentHash: string
supersedesVersion: string | null   # required key; null if first version

Adoption of a formalised version (ValuesAdopted, PolicyAdopted, SchemaAdopted) is a commit type referencing the formalise event by id — step 3 of the normative artifact ladder.

Design rule: if a field is epistemically load-bearing for that capture mode, make it required on the type — not an optional comment in a shared schema. type implies capture mode; consumers should not need a parallel captureForce field on every instance when the contract is authored honestly. (Dynamic ingest pipelines that cannot know type at authoring time are the exception — they should still emit one of the closed families above at capture time, with validation, not a generic untyped row.)

This extends familiar envelopes (CloudEvents, Kafka headers) without replacing domain type on commits. Think: measure / assert / formalise types = how evidence entered; commit type = what the business bound, plus the accountability block.

Append-only discipline: amend means a new event, not mutation — patterns in When Facts Are Wrong.

Validation methodology — how we stress-tested the claim

Claim (strong): every tier-one capture is exactly one of commit · assert · measure · formalise.

Claim (adopted for implementation): every tier-one capture has one primary force.

Procedure

1. Enumerate cases — domain event names (business verbs, not CRUD), integration patterns, scientific workflow, blockchain, LLM pipelines, governance binds, and edge cases that might falsify the four-way split.
2. Ask two questions per case: (a) How did this become evidence? (b) Is the verb domain description or capture mode?
3. Classify into force, or reject as derive / not-logged.
4. Seek falsification — any tier-one capture that fits none of: bind, forward-without-bind, transduce, inscribe.
5. Document composites — relay = measure + commit; derive stays off tier one.

Exhaustiveness argument

A record enters as evidence when an agent or instrument performs one of:

1. Binds → commit
2. Puts forward without binding → assert
3. Transduces through instrument chain → measure
4. Inscribes symbolic structure → formalise

Anything else either does not enter the permanent log (read, in-memory derive, cache), enters wrongly as tier one when it is derive, or is an effect class in the catalogue below that still maps to one of the four — distinct from event type naming; see Domain Events Are Not CRUD.

Stress-test catalogue

Event type uses domain verbs on commit types — not CRUD. The table is not a naming guide or production schema. It lists typical and edge cases we ran against the four forces. A closed global taxonomy is not the goal: real domain catalogues would likely run to >100 entries (hypothesis). In production, supersession, tombstone, adoption, and the rest are ordinary commit type names plus payload (e.g. originalEventId) and the fixed accountability block — each instance typed honestly, not a generic row with mode left implicit.

Result: no case yet found that requires a fifth primary mode — including values, obligations, governance, and tombstone, which all enter as commit. Normativity changes what is bound and who must answer, not how evidence entered the log. Relay is not atomic capture — it is measure + commit. Derive is explicitly not tier-one capture.

Invitation: If you have a tier-one capture that is none of: binding, non-binding forward, instrument transduction, symbolic inscription — that is a falsification. Submit the case; the ontology should bend or break honestly.

Why this matters for event-driven architecture

Most EDA guidance names domain events well and provenance unevenly. Typing capture mode — measure, assert, formalise, and commit schemas with required accountability fields — gives you:

• Audit that answers bind vs measure vs assert without parsing domain verbs
• Projections (derive) kept off tier one, separate from typed substrate
• Failure modes aligned to type family — forged commit vs distorted measure vs assert promoted to fact
• AI pipelines that log L-β as honest assert (see Thinking by Writing) without collapsing assert into commit
• Forward-only corrections — supersession, retraction, tombstone — as ordinary commit types, not silent edits
• Thought topology — typed events with correlationId and causationId let measurements, pre-bind thoughts, inscribed rules, and commits compose into dynamic networks (linear, tree, DAG, or fan-out/broadcast) — not only chains inside one model; see Reasoning Topology and Thinking by Writing

This is not a replacement for domain modeling. It is the epistemic discipline underneath it — the same way commitment status (committed vs uncommitted derivation) orthogonalises atomicity and uncertainty as Part III facets.

In most event contracts, capture mode belongs in the type definition — declared when the event type is authored, with required fields fixed per family. Per-instance mode flags are a documented exception for heterogeneous ingest, not a substitute for typing at the boundary.

Where tier one sits

If you are reading in order, you already have a three-level spine from Part II — not the full epistemic ladder yet:

Article 6 stated the key distinction: tier one sits beneath claims — not “very strong claims” but events reasoning is about — and named the limits of what substrate can claim. This article names how those captures enter. Capture forces apply only at tier one. Tier zero is what captures are about; tiers two and above are claims supported by captures — never confused with the Real or with bare substrate.

The tier spine map summarises only what Part II has established so far; it does not introduce the full claim ladder or Part IV machinery.

Next: thinking by writing — emission layers, L-β capture, and reasoning topology on the event log (Thinking by Writing). Then Part III — the line where conjecture becomes binding consequence (The Moment of Commitment).

Continue → Thinking by Writing

Principle: Tier-one events declare capture mode.