Builds, deployments and investigation
Validate a Context Build, serve it to an application, promote carefully and learn from traces.
Builds, deployments and investigation
There are two related release paths. A Context Build freezes context design, observed source revisions, embedded material and test results. An agent release also binds saved behavior, knowledge, capabilities and a model connection, and requires a current agent evaluation. Choose the Context path when your application already runs the model; choose the Agent Workspace when SEIF should run the agent turn.
Validate and build context
In Context engineering, use Test → Run all to check representative queries. Build → Validate checks tests, source pinning, portability and secrets. Correct blocking findings, then select Build. A new Build gets an immutable digest. Compare it with a previous Build before promotion to see changed rules or source revisions. An existing Build does not change when you edit a project file.
The browser can validate and create Builds, but deployment and trace investigation are local workflows today. In the desktop Workstation, Observe → Run can serve a selected Build locally on http://127.0.0.1:4317. Send test request exercises it and produces a trace. Integrate provides curl, Python and TypeScript snippets; your application calls POST /v1/context/resolve and receives provider-neutral messages and reasons. It must still call a model itself and enforce its own user permissions.
Promote and deploy
For managed local release operations, start the personal Build Registry, register the Build and let the Registry verify it and rerun its tests. Compare a candidate to retained regression obligations, promote it to an environment, then deploy. Promotion alone does not move a running route. Wait for a healthy runtime before pointing an application at its authenticated endpoint. Production uses a reviewer approval policy by default. A rollback selects an older immutable Build and preserves history; it does not erase the faulty release.
Runtime provider endpoints and secrets are deployment bindings. They can differ between development and production without changing the Build. Keep the application credential scoped to the audience and environment it serves; it cannot edit a project or approve agent actions.
Investigate what happened
Open a Context Trace to inspect its Build, source observations, inclusion and exclusion reasons, binding and delivered messages. The distinction matters: rendered means SEIF produced the material, delivered means the application received it, and consumed remains UNKNOWN unless the application reports what it actually sent to a model. Compare the historical trace with a candidate Build. When the retained request and dependencies support it, confirm the intended expectation and turn the incident into a regression test. The observed failure is evidence, not an automatically correct test oracle.
See concepts for the vocabulary and project files for test syntax.