SEIF Context Builds
A Context Build is the product's output: the reproducible behaviour that resolves context — not a snapshot of one context.
builds/build-0001/
context-build.json manifest (read-only)
materials/<sha256>.txt embedded material, content-addressed (read-only)
source.json a project made of files: its authoring files as built (read-only; never team/ records)context-build.json (seif-context-workstation.context-build.v1):
| Part | Contents |
|---|---|
buildRef, name, version | support-agent-context@1. Versions only increase; a Build directory is never overwritten. |
digest | sha256: over the canonical JSON of definition. |
definition (digest-covered) | runtime contract (seif.context-runtime.v1), project identity, the target environment, consumers, objectives, Context Profiles and rules, layers and bindings, render configuration and budgets, test definitions, explicit coverage decisions (gapDispositions), sources with pinned revisions (no machine paths), the material index (locator, digest, estimated tokens, metadata), required capabilities, and unpinned dependencies (live sources, incomplete observations). |
validation | test summary and per-assertion results at build time, warnings (e.g. WORKTREE_MODIFIED), releaseQuality. |
provenance | the saved design digest, source observations (revision, observed time, Git branch/work-tree state), engine version. |
createdAt, createdBy | outside the digest. |
source | { files, digest } of source.json: the project's authoring files (agents, knowledge, policies, tests, connections) as they were built, outside the definition digest. They let a server answer exactly as this Build: the hosted context server's production environment serves the newest Build of release quality from them (materializeBuild checks the files make the project whose design digest the Build records). Builds made before this have no source and are not served; make a new one. |
Reproducibility. Same project definition + same source revisions + same runtime contract → the same digest (creation time, version number and observation times are excluded). The test suite builds the reference project twice from independent folders and compares digests. Dynamic inputs are declared, never hidden.
Scope-boundary decisions. A Gap can be recorded as deliberately uncovered with a reason and, when known, its redacted source interaction. This is authoring state, not deletion of a historic gap. The decision is inside the Build definition and can be cited only after tests pass and a Build is published: Build <ref> + digest + gapDispositions/<id>.
Immutability. Files are written once (atomic rename) and made read-only; every load recomputes the definition digest and every material digest. A modified Build is reported as BUILD_INTEGRITY_FAILED in Build History and refused by the runtime.
Validation blocks a Build for unobserved/unavailable sources used by a profile, credential-like material (SECRET_DETECTED), machine-specific absolute paths in the definition, or (unless overridden) required tests that do not pass. A Build is made from the saved design; a draft must be saved first.
History and comparison. BUILD lists every Build (version, ref, created, digest, tests, pinned sources, warnings, verification). Compare Builds reports semantic rows: source added/removed/revision changed, consumer/objective/profile/rule/budget/render changes, layer bindings, tests, materials added/removed/changed, runtime contract. Project edit vs Build compares the saved design and current sources with a Build.
Registration, trust and compatibility
Existing v1 Builds remain executable and retain their definition digest. Engines 0.3.0 and 0.4.0 use the same seif.context-runtime.v1 contract and refuses incompatible contracts. Registry registration additionally computes a complete artifact digest covering the immutable manifest, provenance and material mapping. A Build ref cannot be reassigned; retrieval re-verifies storage. Ed25519 signing binds both digests, identity, contract and provenance. Signature state is independent of tests and promotion.
Promotion changes environment references, not Build bytes. A Build's compiled environment remains its policy basis; operational deployment environment is a separate trace fact. Pinned HTTP/MCP material is embedded; live connectors and external retrieval explicitly mark unpinned dependencies. Executability is not a claim of complete reproducibility. See Registry and ADR 003.
Versioned tools
Context and tool delivery documents tool declarations and profile rules, v2 tool Builds, executor bindings, synthetic tests, operator approval, SDK integration and effect-free replay. Tool-free Builds preserve the v1 contract.