SEIF ADR 002 — Context Project, Build, Runtime and Trace
Accepted 2026-10-08. Supersedes the primary-journey assumption of ADR 001 ("open an existing SEIF Workspace"). ADR 001's desktop stack and canonical-process boundaries remain in force for the Advanced SEIF Workspace surface.
Decision
The primary product loop is Connect → Design → Test → Build → Run → Observe → Improve. Its output is a Context Build, executed by a Context Runtime that answers POST /v1/context/resolve and records a Context Trace for every resolution.
Context Project, Context Build, Context Runtime and Context Trace are Workstation product/application concepts. They are not SEIF Protocol ontology and do not become new semantic owners. They compile into, and are executed by, existing SEIF mechanisms:
| Product concept | Existing SEIF mechanism used underneath |
|---|---|
| Objective → resolved job | resolveTurn (@and2carvalho/seif-application): explicit objective is EXPLICIT_PRODUCT_ACTION; the Consumer default is COORDINATE_DEFAULT; no LLM interpretation |
| Context Profile rules → selection | selectContextWithPolicy (Context Kernel): component order = layer priority, available = observed layers, decide = compiled rules → inline / on-demand / omitted / missing-required + reasons |
| Selected material → projection | DagContextRuntime + one FacetResolver per Context Layer; ContextProfile { name, facets, policies }; per-facet content revisions |
| Resolution status | createSeifApplication(...).prepareTurn() → createApplicationTurnPlan (executable / blocked: MISSING_REQUIRED_CONTEXT, RENDERING_INCOMPLETE) |
| SEIF provider | EmbeddedProvider (@and2carvalho/seif-application/embedded) — the supported SEIF mode for a host application; no CLI, daemon, Engine or managed Workspace is required |
| Trace records | projectApplicationTurnObservation + toApplicationTurnObservationRecord (canonical application.turn.prepared.v1), wrapped with Workstation context.* records in the public seif.observation-trace.v1 envelope (@and2carvalho/seif-observability/wire) |
| Build / resolution comparison | diffProjections over per-facet revisions, plus Workstation semantic diff rows |
| Expansion staleness | isStaleRef (ref sourceRevision = Build digest, resourceRevision = material digest) |
The Workstation authoring rules (participation, mode, priority, max items, currentness, required, budget) are a small explicit vocabulary that compiles into the Context Kernel policy and the ContextProfile. The engine does not introduce a competing projection or selection engine.
Why no managed SEIF Workspace per Context Project
The SEIF distribution analysis (docs/research) and the package READMEs establish the embedded Application provider as first-class and independent of CLI/daemon/Engine. A managed Workspace would add a registry write to the customer's home, a CLI dependency at runtime, and no capability the loop needs (identity, projection, observation and evidence are supplied by the embedded mode). The Workstation therefore does not create one. An existing SEIF Workspace remains available through Advanced → Open existing SEIF Workspace, which keeps the previously proven Product, expansion, Evidence and governed-effect behaviour unchanged.
Engine placement
One engine implementation (runtime/engine/*.mjs, plain ES modules) runs in three places, so design-time preview, Context Tests, and the deployed runtime resolve identically:
- Workstation design time — one-shot JSON over stdio (
engine/cli.mjs), like the existingapplication-host.mjs. - Workstation Run Build —
engine/server.mjschild process bound to loopback. - Exported Context Runtime Bundle — the same
server.mjswith the pinned Node binary and the four public SEIF packages; no Workstation, source checkout, global Node, Go or .NET.
C# owns presentation, project editing, process lifetime and the UI state machine. It never re-implements selection, rendering, budgets or digests.
Semantics fixed by this decision
- Path is a locator, never identity. Project, source, layer, consumer, objective and profile ids are explicit.
- Build digest = SHA-256 of canonical JSON of the build definition (project design + pinned source revisions + material digests + runtime contract). Creation time, version number, test durations and observation times are outside the digest. Builds are written once, made read-only and verified on load.
- Source connection never implies authority. Every layer reports
access: READ_ONLY; no runtime path writes to a source. DESIRED ≠ SELECTED ≠ MATERIALIZED ≠ PROJECTED ≠ RENDERED ≠ CONSUMED. Consumed isUNKNOWNuntil the consumer reports it throughPOST /v1/context/consumption.- Token counts are estimates (
ceil(chars / 4)), labelled as such everywhere. - Traces retain identity, reasons, digests and metadata by default. Rendered content is retained only when the Build's environment says
traceRetention: "content", with a bounded size and count. - Runtime binds loopback by default; any non-loopback bind requires a bearer token of at least 24 characters. Browser-origin requests are refused.
- Git sources pin the committed tree at
HEADread directly from the repository (nogitexecutable). Uncommitted changes are reported asWORKTREE_MODIFIED, never silently included.
Alternatives rejected
- Re-implement resolution in C#. Would duplicate SEIF selection/projection semantics and diverge from the runtime.
- Ship the bundled SEIF CLI inside the Context Runtime. The Product/Workspace surfaces resolve SEIF development estates, not customer context; they would make the runtime depend on Workspace markers and the Go toolchain's output for no customer value.
- Single
context.jsonsnapshot as "Build". Not executable; loses rules, budget, tests and reproducibility. - LLM-based selection or judging. Non-deterministic; fundamental assertions must be structural. An Advisor may later propose, never mutate.