Concepts and mental model
Understand sources, layers, profiles, Context Builds, runtimes, bindings and traces.
Concepts and mental model
Context is a release artifact. Your agent's answer depends on what it receives, not merely on its model or prompt. SEIF lets you inspect and test that input before it reaches the model.
| Term | Meaning |
|---|---|
| Context Project | The editable Markdown/YAML folder that defines an agent's context. It can live in Git. |
| Source | Where material comes from: a file, folder, Git revision, inline text or supported connector. |
| Layer | A named collection of material with a role, such as product policy, public knowledge or private notes. |
| Consumer / objective | Who is asking for context and for what task. These select a Context Profile. |
| Context Profile | The rules that decide each layer's participation, retrieval, priority and budget for an objective. |
| Context Test | A deterministic scenario that checks required/forbidden material, status and token ceiling. |
| Context Build | An immutable artifact of design, pinned source observations, embedded material and test results. |
| Deployment Binding | Per-environment runtime settings and references to live providers or secrets. The Build remains unchanged. |
| Context Runtime | An HTTP service that resolves a Build for an application request. |
| Context Trace | The observed record of a resolution: which Build and material participated and why. |
The selection path
Available → applicable → desired → selected → materialized → projected → rendered → consumed. These stages are intentionally separate. A document may exist but not apply to a task. A selected document may still be excluded by budget. A rendered message may be delivered to your application, while actual model consumption remains UNKNOWN unless the application reports it. Token numbers are estimates, not provider bills.
Three useful flows
Build a support agent: put public policy in one layer and internal account notes in another. Exclude the internal layer from customer answers. Preview a refund request, create a test that requires the policy and forbids the notes, then Build.
Ship live data safely: keep stable instructions and knowledge in the Build. Declare a runtime provider for order status, then bind the provider endpoint and secret in each environment. The trace identifies which binding and provider version supplied the live fact.
Investigate a failure: choose the production trace, inspect its exact Build and material, compare the current design, confirm what should have happened and add a regression guard. The next release must satisfy the retained expectation.
The browser guide covers the first flow. The local guide and advanced workflows cover runtime and investigation.