Trace to Decision Walkthrough

This walkthrough shows one complete supported alpha path for a non-Python application:

  1. a TypeScript client submits a TRACE
  2. the evaluator service runs the canonical Python runtime
  3. the service returns a normalized decision plus audit metadata
  4. the deployment records an orthogonal flag, a trust-debt update, and an audit record

This is a deployment-side artifact chain around the canonical protocol surface, not an alternate protocol schema.

It is the supported non-Python path in alpha because Python is the canonical runtime evaluator and non-Python applications should call an evaluator service for execution-time governance.

Scenario

The operating agent handles customer-support refunds.

  • order A-1007 is eligible for refund
  • the requested amount is below the hard stop threshold
  • the order evidence and receipt evidence match
  • the customer changed their account email 12 hours ago, so the deployment adds a follow-up fraud-review flag

Primary decision and orthogonal flag stay separate:

  • intervention: ok
  • flag: true

That is the supported alpha model. Flags do not replace the primary intervention value.

Deployment Mode Used

This example uses the repository's reference deployment posture:

  • TypeScript client calling the evaluator-service boundary
  • Python GovernanceSteward as the runtime evaluator
  • PostgreSQL for request metadata, audit persistence, and runtime state
  • SQLite remains a developer and single-node fallback path, but it is not the runtime-state backend used in this walkthrough

See Reference Deployment for the topology.

1. Policy Artifact

The policy artifact is the blueprint applied by the Python runtime.

Key points:

  • refund_hard_cap blocks only very large refunds
  • the example request stays under the hard cap
  • the artifact uses the same canonical source-blueprint vocabulary as the Standard quickstart
  • trust policy is enabled, so a flag still changes deployment posture over time

2. Request Artifact

The TypeScript client sends a request body whose trace uses the same canonical trace vocabulary taught in ACGP-3 and the Standard quickstart.

Minimal client code using the supported SDK path:

import { createEvaluatorServiceClient } from '@acgp-protocol/sdk';

const client = createEvaluatorServiceClient({
  baseUrl: 'https://governance.example.com',
  apiToken: process.env.ACGP_EVALUATOR_TOKEN,
  timeoutMs: 3000,
  retry: {
    maxAttempts: 3,
    baseDelayMs: 200,
  },
});

const response = await client.evaluateWithDetails(trace, {
  metadata: {
    client: 'typescript-evaluator-client',
    deployment_mode: 'reference',
  },
});

3. Decision Artifact

The evaluator service returns the primary intervention plus audit metadata.

What this decision proves:

  • the supported TypeScript path is a service client, not a local runtime evaluator
  • the primary intervention remains ok
  • the orthogonal flag stays represented as flags.flagged: true on the decision surface
  • the service still returns audit identifiers and normalized governance status

4. Flag Artifact

The deployment emits a separate follow-up flag record because the account changed recently.

This is why ACGP treats flagging as orthogonal:

  • the refund can proceed under Standard policy
  • the deployment still queues a fraud-review follow-up
  • the separate record is deployment/audit material, not a second canonical intervention model

5. Trust-Debt Artifact

Because the evaluation was flagged, trust debt increases even though the primary intervention is ok.

This example crosses the elevated_monitoring threshold exactly, which is useful because it shows a deployment posture change without forcing an immediate block or halt.

6. Audit Artifact

The audit record ties the evaluation together.

The important connection points are:

  • same trace_id across request, decision, flag, trust-debt update, and audit record
  • same audit_id on the returned decision and persisted audit entry
  • explicit note that the shipped reference deployment persists both audit metadata and runtime state in PostgreSQL

Conformance Note

This walkthrough stays inside the active alpha claim surface:

  • Standard is the claimable profile used here
  • the request is a single TRACE, not an out-of-scope heterogeneous batch
  • the evaluator path is the supported Python-runtime service boundary
  • the orthogonal flag is not treated as a standalone primary intervention value

Where To Use This Example