The anatomy of a run
A run records more than a question and an answer. Each of the stages below is captured, and the worked examples show them in this order.
- 6.1
The exact user prompt
Shown as entered. It is part of the run record and is separate from EKA's own static mission and planner instructions.
- 6.2
Page or conversation context
A compact semantic reference such as SOURCE / CRM / opportunity / OPP-2026-900006 helps EKA know what “this” means. It is still only a reference hint: the runtime re-reads the governed record before treating anything as evidence.
- 6.3
The prompt supplied to the model
Two logical model stages, planner and synthesis, under one fingerprinted prompt bundle.
- 6.4
Structured interpretation
A concise interpretation plus explicit requested parts: subject, record if known, required features, and the steps that serve that part. This is the inspectable plan contract, not private chain-of-thought.
- 6.5
Required-feature resolution
Before relying on a feature, the runtime resolves whether it is actually available for the requested subject and viewer. Naming an alternate does not authorize EKA to read it in place of the requested authority.
- 6.6
Runtime validation and re-planning
A model-produced plan is only a proposal. A rejection becomes structured feedback for another planning round, and the examples preserve those events when they happened.
- 6.7
Governed tools and access
Tools execute only after validation, and all reads are viewer-aware. Each run shows tool, step, status, execution time, authority, and whether evidence was withheld.
- 6.8
Typed evidence
Tool results are normalized into typed evidence. Synthesis cites evidence IDs issued by the runtime; an invented citation is not accepted.
- 6.9
Calculations
Deterministic runtime operations rather than model arithmetic. Money is either a single currency or explicitly grouped by currency. There is no implicit FX conversion.
- 6.10
Claims and support
Each statement carries its own support state, so an established absence and an unestablished cause can sit in the same answer.
- 6.11
Overall result state
How much of the user's request was fulfilled. Feature availability and overall result state are separate concepts.
- 6.12
Captured answer vs public wording
Every example carries both: what the run produced, and wording cleaned only where clarity or precision needed it. The underlying evidence, run status and technical behavior are not rewritten to make a prettier demo.
- 6.13
Run metadata
Run ID, model calls, prompt fingerprints, build, business time, tool-call count, evidence count, duration and contract versions — so a historical run answers not only what EKA said, but which configuration produced it.
mission + planner instructions + relevant QSR subjects + registered tools and their schemas + page/task context + previous runtime feedback on re-plan + user question → structured JSON plan
mission + authorized evidence + runtime notes / feature resolutions + user question → answer + claims citing evidence IDs
The complete static prompt material is in Appendix A; it contains no business values. The guide does not publish the fully rendered dynamic prompt for each turn, because those rendered prompts can contain user context and authorized enterprise evidence.
- unknown subject
- unknown feature
- invalid relationship type
- invalid cross-subject key use
- bad dependency
- invalid aggregate
- unregistered tool
An example of feature resolution, as the runtime records it:
canonical.SalesOrder.STATUS → AVAILABLE canonical.SalesOrder.AMOUNT → NOT_PRESENT available elsewhere: source.ERP.erp_sales_order.total_amount
EKA does not treat every retrieved item as interchangeable context. Typing the evidence is what lets the final answer keep a recorded fact, a derived result, a document assertion, a recorded relationship, an absence, an inference and an unknown apart.
- STRUCTURED_FACT
- RELATIONSHIP
- DOCUMENT_PASSAGE
- SCENARIO_ASSERTION
- RECORD_LINEAGE
- FIELD_LINEAGE
- RESOLUTION_EVIDENCE
- OPERATIONAL_LINK
- AUDIT_EVENT
- DERIVED_RESULT
- ABSENCE
Claim support
Per statement in the answer.
- ESTABLISHED
- SUPPORTED
- NOT_ESTABLISHED
- CONTRADICTED
- UNKNOWN
Overall result state
Per run, describing how much of the request was fulfilled.
- COMPLETE
- PARTIAL
- EMPTY
- AMBIGUOUS
- NOT_FOUND
- FORBIDDEN
- UNAVAILABLE
- INVALID
If a governed relationship is recorded, EKA can establish that the relationship exists. That does not automatically establish why it was created or which rule created it. Relationship existence and relationship derivation are different claims, and where derivation provenance does not exist, EKA says so rather than inventing it.
Chapter takeaway
- A plan is a proposal; validation and re-planning are part of the record.
- Evidence is typed, and citations are issued by the runtime.
- Claim support and result state answer different questions.