Evidence lifecycle

Themis treats a release run as a sequence of evidence steps.

The lifecycle

Step	What happens	Why it matters
1. Define	The manifest names the baseline, candidate, dataset, context, and cases.	It makes the question explicit.
2. Identify	Themis validates the dataset source and content identity.	It prevents comparison with the wrong data.
3. Propose	An optional agent returns read-only SQL and metadata.	It tests the real agent boundary.
4. Freeze	Themis uses a stable snapshot for the run.	The same input gives a reproducible check.
5. Replay	Themis executes the candidate artifact.	It observes the candidate behavior.
6. Oracle	Themis calculates the expected result separately.	It avoids trusting the candidate alone.
7. Ground	Themis reads DataHub evidence through MCP.	It checks meaning, ownership, lineage, and quality.
8. Trace	Themis records runtime OpenTelemetry IDs.	It links the work to real execution spans.
9. Decide	Policy combines the required signals.	It returns a deterministic outcome.
10. Record	Themis writes a redacted receipt.	A person can review the run later.

Why the order is important

The same SQL can produce different results on different data. The same result can have a different meaning when a field is deprecated. A trace can prove that the code ran, but not that the answer is correct.

Themis keeps these facts separate. It does not use one green signal to hide a missing signal in another part of the run.

Evidence quality

Themis distinguishes these states:

• Observed: a trusted runtime returned the value.
• Unavailable: the system could not return the value.
• Not configured: the optional component was not enabled.
• Ablated: the run deliberately disabled a required component.
• Error: the component ran but returned an error.

This vocabulary prevents a missing component from looking like a pass.