Skip to content

Versioned Context Manifest

Manifest artifact — instantiates Definition-Time Context Binding

An itemized manifest of every context reference a behavior was bound to — schemas, identities, definitions — each tagged with its version and provenance, so a later execution resolves them to the same versions it was defined against.

A versioned context manifest is an explicit, itemized record of the context a behavior unit was bound to — the schemas, rulebook versions, identity definitions, locales, and named references it depends on — with each entry tagged by the exact version in force and its provenance. Where a configuration snapshot freezes config values for reproducibility, this manifest enumerates the reference set and its versions so that a later or relocated execution can resolve every nonlocal name to the same definition it was written against, and a reviewer can see precisely which versions governed. Its defining move is making the bound context legible and version-pinned: not the behavior, not its authority, but a declared inventory of "these are the versioned things this unit resolves against."

Example

A loan-approval workflow is paused for a manual document check. Its manifest records that it is bound to underwriting-rulebook v7.2, applicant-schema v3, the KYC identity definitions as of the submission date, and regional rate-table v2026.2 — each with provenance.

When the case resumes four days later on a different node, after a rulebook release to v7.3, the workflow resolves against the manifested v7.2, so the applicant is judged under the rules in force when they applied rather than the newer ones. The manifest is also what an auditor reads to confirm which versions decided the case. Moving the paused case from v7.2 to v7.3 would be an explicit, recorded migration — never a silent resolve to "current."

How it works

  • Inventory the nonlocal references. Enumerate every schema, definition, identity, and named dependency the behavior resolves but does not itself contain.
  • Pin a version and provenance per entry. Record the exact version in force and where it came from, so each reference has an unambiguous target and an audit origin.
  • Resolve against the manifest, not the ambient. At execution, nonlocal names bind to the manifested versions; a missing entry is a rejection, not a silent fallback to "latest."
  • Diff across versions. Because entries are versioned, two manifests — or a manifest versus current — can be compared to see exactly what a rebind would change.

Tuning parameters

  • Manifest breadth — how many references are pinned; under-listing leaves nonlocal names to resolve ambient (drift), over-listing pins things that were never really dependencies.
  • Value vs. pointer per entry — inline the definition or reference it by version id; pointers keep the manifest light but require the versioned target to stay resolvable.
  • Version identifier scheme — semantic versions, content hashes, or effective-dates; hashes are precise, dates match "as of when authority was delegated," semver signals compatibility.
  • Resolution-on-missing policy — hard-reject versus pinned-default when a manifested version is unavailable; rejecting protects meaning, defaulting protects availability.
  • Diff / compatibility strictness — how much version divergence is tolerated before a resume is blocked pending migration.

When it helps, and when it misleads

Its strength is making "which definitions governed this?" both answerable and enforceable — the archetype's target that every nonlocal dependency has a documented resolution source, and that a long-lived behavior can survive context-version change without silently changing meaning. On resume or handoff, references bind to the versions the author intended.

The manifest is only as good as its completeness: a reference left off the list resolves ambient and reintroduces exactly the drift it was meant to prevent (partial capture). Pinning old versions forever risks running on stale, since-deprecated definitions; the honest counterpart is an explicit migration, not silent rebinding.[1] The classic misuse is treating the manifest as also guaranteeing the context — its authenticity or correctness — when it only records versions; sealing that record is a separate mechanism. The discipline is to pin every nonlocal reference (or prove it constant), prefer precise identifiers, and route version changes through a reviewed migration rather than editing the manifest in place.

How it implements the components

  • captured_environment_manifest — the itemized inventory of bound references is this manifest.
  • context_version_and_provenance — each entry carries the version in force and where it came from, the record that lets a later run resolve correctly and an auditor trace which versions governed.

It records the bound context; it does not freeze config values for replay (Versioned Configuration Snapshot), seal itself against tampering (Signed Context Manifest), serialize and transport the unit (Serialized Job Envelope), or perform a version change — moving from one manifested version to another is a Context Migration Record.

Notes

A configuration snapshot and a context manifest are easy to conflate: the snapshot pins values so a run reproduces the same outputs, while the manifest pins which versioned references a run resolves against so its meaning stays fixed. A single execution often needs both — binding to a config snapshot and declaring a context manifest — and the two answer different questions (reproducible outputs versus correct resolution).

References

[1] Version skew — components resolving the same reference to different versions — is a standard cause of "worked when defined, broke when resumed." Disciplines such as schema evolution manage it by versioning definitions and negotiating compatibility explicitly; a versioned context manifest is the record that lets a resumed behavior demand the version it was bound to instead of inheriting whatever is current. ↩