ponens

← All specifications

Trace, Policy, and Review-Case Semantics

Version

Version: 0.2
Status: Draft
Purpose: Clarify the distinction and relationship between the trace specification, policy specification, and review-case specification, and define how policy satisfaction is interpreted over traces and review-case context

1. Three Connected but Distinct Specifications

The computable governance framework is built on three separate but connected specifications:

  1. a trace specification
  2. a policy specification
  3. a review-case specification

These should be treated as distinct but composable semantic layers.

1.1 Trace specification

The trace specification defines the execution record and its formal semantics.

It describes:

A trace is therefore not just a log format. It is a typed execution structure with formal meaning.

1.2 Policy specification

The policy specification defines:

A policy is therefore not a trace object. It is a constraint or formula interpreted over traces and, optionally, review-case state.

1.3 Review-case specification

The review-case specification defines:

A review case is therefore not a trace and not a policy. It is the governed workflow context within which traces are produced, reviewed, and approved.

1.4 Relationship between the three

The dependency structure is:

Trace semantics ─────────────┐
                             ├──> Policy semantics / satisfaction
Review-case semantics ───────┘

A more workflow-oriented reading is:

Trace semantics
    ↓
Review-case semantics over traces
    ↓
Policy semantics over traces and review-case context

Both views are useful:

2. What a Trace Is Semantically

A trace is a typed execution structure representing one concrete run of an AI agent workflow.

Semantically, a trace contains:

2.1 Informal semantic view

A trace is the record of:

2.2 Operational semantic view

A trace can be viewed as a sequence of state transitions:

TraceState_0 --(Action_1)--> TraceState_1 --(Action_2)--> ... --(Action_n)--> TraceState_n

Each action may:

This gives the trace an operational interpretation, not just a documentary one.

2.3 Structural semantic view

A trace also induces one or more graph structures:

These structures are semantically meaningful and may be referenced by policy formulas.

2.4 Trace semantics as domain of discourse

The trace specification defines the objects and relations that policies can talk about at execution level.

Examples include:

A trace is therefore the execution substrate of the governance system.

3. What a Review Case Is Semantically

A review case is the workflow-level object that governs one or more traces over time.

A trace shows one run. A review case shows where the overall governed change stands.

Semantically, a review case contains:

3.1 Informal semantic view

A review case is the record of:

3.2 Workflow semantic view

A review case does not redefine the internal structure of traces.
Instead, it organizes them into a governed solving process.

It answers questions such as:

3.3 Governing principle

The core invariant is:

All meaningful current modifications should retrace to the original problem formulation through the review-case graph, and all steps used to reach them should remain within policy.

This makes the review case more than a ticket or container.
It is a governed solving context.

3.4 Review-case semantics as domain of discourse

The review-case specification defines the objects and relations that policies may talk about at workflow level.

Examples include:

A review case is therefore the workflow substrate of the governance system.

4. What a Policy Is Semantically

A policy is a well-formed formula in the policy DSL interpreted over a trace and, optionally, review-case context.

Policies do not create execution history.
They constrain, require, forbid, or validate properties of that history and context.

4.1 Informal semantic view

A policy expresses a governance rule such as:

4.2 Policies as predicates over traces and review cases

Semantically, a policy is a predicate over:

A policy may refer to:

4.3 Temporal + structural + workflow nature

The policy language is not only temporal.

It may include:

So a policy is best understood as a governance formula over a structured execution-and-workflow model, not just as a simple temporal rule.

4.4 Policy semantics depend on trace and review-case semantics

A policy formula only has meaning relative to the semantics of the objects it refers to.

For example:

Therefore, the policy DSL must be interpreted with respect to the trace specification and, where used, the review-case specification.

5. How Policy Satisfaction Is Defined

The key semantic relation is:

A trace or review-case context satisfies a policy if the policy formula evaluates to true over the relevant semantic structures.

5.1 Trace-only satisfaction

Let:

Then:

τ ⊨ φ

means:

trace τ satisfies policy φ

and:

τ ⊭ φ

means:

trace τ does not satisfy policy φ

5.2 Review-case-context satisfaction

Let:

Then satisfaction may be evaluated relative to the combined context:

(c, τ_active(c)) ⊨ φ

meaning:

review case c, together with its relevant trace context, satisfies policy φ

5.3 What evaluation may depend on

Evaluating policy satisfaction may depend on:

6. Examples of Satisfaction Contexts

6.1 Trace-only example

A policy like:

G(GitCommit -> P(RunTests /\ completed))

is satisfied if, at every commit action in the trace, there exists an earlier test action satisfying the required condition.

6.2 Structural trace example

A policy like:

G(GeneratedTests -> ancestor_of(StateSpaceAnalysisResult, GeneratedTests))

is satisfied if every generated-tests artifact has the required upstream state-space analysis evidence in its lineage.

6.3 Review / approval trace example

A policy like:

G(high_stakes_edit(a) -> F approval_action_for(a))

is satisfied if every high-stakes edit is eventually followed by the required approval action.

6.4 Review-case workflow example

A policy like:

ReadyForApproval(review_case) -> not blocking_items_open(review_case)

is satisfied if a review case only enters approval-ready state when no blocking case-level review items remain open.

6.5 Explanation-status example

A policy like:

Approved(review_case) -> explanation_status(review_case) = Explained

is satisfied if a review case can only be approved when the current work remains fully explained by the original problem and active trace.

7. Best Architectural Rule

The architectural rule is:

Traces define execution semantics, review cases define workflow semantics over traces, and policies define the governance logic evaluated over those structures.

This implies:

8. Recommended Specification Structure

To make this distinction explicit, the system should now be documented as four linked pieces:

8.1 Trace Specification

Defines:

8.2 Policy Specification

Defines:

8.3 Review-Case Specification

Defines:

8.4 Binding Specification

Defines:

This fourth piece is the bridge that turns the three semantic specifications into one coherent system.

9. Current Architecture and Remaining Open Work

The architecture is now more mature than when this note was first written.

9.1 What now exists

There is now a clearer split between:

9.2 What remains open

The main remaining open work is:

A. Binding specification

A dedicated document or section defining:

B. Snapshot specification

A dedicated snapshot specification for:

C. Explanation algorithms

A precise specification of:

D. Case-level policy semantics

A more formal treatment of:

E. Projection / serialization guidance

A unified guide for:

10. Summary

The clean conceptual distinction is:

Or, in one sentence:

Traces capture runs, review cases govern the broader solving process, and policies define the rules evaluated over both.