Recorder Asset Core Decision Gate
Docs
Decision Gate Docs

Deterministic, replayable gate evaluation with auditable decisions.

Asset Core docs

LLM Authoring Contract

Purpose and Audience

What: The canonical, single-document contract for LLM-driven Decision Gate authoring. Why: Enforce deterministic, evidence-backed checks before consequential actions. Who: Teams integrating LLM agents with Decision Gate in fixed workflows or self-authoring loops. Prerequisites: evidence_flow_and_execution_model.md

This is the primary document to hand to an LLM. Other guides are optional depth. For a single human onboarding path covering guarded execution, DG-as-skill evaluation, and recursive composition, see skill_pathways_onboarding.md.

Reference Implementation

For a concrete legal-claim implementation of this contract (offline deterministic plus live opt-in operation), see:

Non-Negotiable Invariants

  1. Decision Gate is an execution boundary, not advisory analysis.
  2. Factual claims that are marked required must be resolved by evidence, not model confidence.
  3. Consequential actions must be blocked when required claims are unresolved.
  4. precheck is iteration-only; consequential paths require live evaluation.
  5. Capability mismatches fail closed.

Canonical Tool Sequence

Use this sequence for every workflow:

  1. Capability discovery
    • providers_list
    • provider_contract_get
    • provider_check_schema_get
  2. Authoring
    • Extract claims
    • Build claim_inventory
    • Compile claim_condition_map
  3. Fast loop
    • schemas_register
    • precheck
  4. Consequential boundary
    • scenario_define (if not already defined)
    • scenario_start
    • scenario_next
  5. Audit/debug
    • runpack_export and/or evidence_query as policy permits

Skills Crosswalk

This document remains the normative protocol. Skills are operational wrappers for using the protocol consistently.

Canonical repo skills:

  • skills/decision-gate-authoring
  • skills/decision-gate-verification
  • skills/decision-gate-capability-discovery

Crosswalk:

Playbook sectionPrimary skillConcrete tool sequence
Canonical Tool Sequencedecision-gate-authoringproviders_list -> provider_contract_get -> provider_check_schema_get -> schemas_register -> precheck -> scenario_define -> scenario_start -> scenario_next
Capability Discovery Handshakedecision-gate-capability-discoveryproviders_list -> provider_contract_get -> provider_check_schema_get
Claim Decomposition Contractdecision-gate-authoringclaim extraction + claim_inventory generation (contract-backed)
Condition Compilation Contractdecision-gate-authoring + decision-gate-capability-discoverycheck schemas + comparator/type validation before claim_condition_map
Execution Contract + Hard Stop Rulesdecision-gate-authoring + decision-gate-verificationprecheck fast loop, then live scenario_start + scenario_next, then runpack_export + runpack_verify
Canonical Agent Prompt Blockall three skillscompact skill instructions that preserve this contract (not a second source of truth)

decision_gate_docs_search queries to support skill workflows:

{
  "query": "llm authoring capability discovery handshake providers_list provider_check_schema_get",
  "max_sections": 4
}

{
  "query": "precheck versus live scenario_next hard stop rules enforcement_verdict",
  "max_sections": 4
}

{
  "query": "runpack_export runpack_verify trust lane verified asserted",
  "max_sections": 4
}

Capability Discovery Handshake

Capability discovery is mandatory before condition compilation in arbitrary domains.

1) List providers

{}

Use the payload above with providers_list.

2) Fetch provider contract

{
  "provider_id": "json"
}

Use the payload above with provider_contract_get.

3) Fetch check schema details

{
  "provider_id": "json",
  "check_id": "path"
}

Use the payload above with provider_check_schema_get.

At minimum, collect:

  • allowed_comparators
  • params_schema
  • result_schema

Claim Decomposition Contract

Every candidate factual statement must be represented in claim_inventory.

Classification rules:

  • gatable = true only when the claim can be deterministically checked against an evidence source.
  • gating_required = true for claims that block consequential actions if unresolved.
  • gatable = false requires a non-empty reason.

Two operating modes are supported:

  • Fixed workflow: humans predefine required claim classes (for example, legal citations).
  • Self-authoring: the agent extracts claims at runtime and compiles conditions from discovered capabilities.

Domain specificity is expected: claims depend on each team’s data sources and access.

Condition Compilation Contract

For each gatable = true claim, compile one or more conditions using:

  • provider_id
  • check_id
  • params
  • comparator
  • expected
  • trust_min_lane

Compilation requirements:

  1. Comparator must be in allowed_comparators from provider_check_schema_get.
  2. params must conform to params_schema.
  3. expected must be compatible with result_schema and comparator semantics.
  4. condition_id values must be unique within the scenario.

Execution Contract

Fast iteration loop (asserted)

  1. Register schema via schemas_register.
  2. Run precheck against asserted payload.
  3. Fix claim mapping, schema, or conditions until required claims evaluate to pass states.

Consequential boundary (verified)

Before any consequential action:

  1. Ensure scenario is defined (scenario_define).
  2. Create run (scenario_start).
  3. Execute live evaluation (scenario_next).
  4. Proceed only if the decision outcome is pass/advance/complete for your boundary policy.

Hard Stop Rules (MUST NOT PROCEED)

Do not allow consequential action when any condition below is true:

  1. A required gatable claim has no mapping in claim_condition_map.
  2. A required mapped condition resolves false or unknown.
  3. scenario_next does not return an allowed pass outcome for the release boundary.
  4. Policy requires verified but only asserted evidence is used.
  5. Provider/check/comparator/type contract validation fails.

Canonical Agent Prompt Block

Paste this into your agent system prompt, then bind the tool layer to DG MCP tools.

You are the Decision Gate Authoring Agent. Follow this protocol exactly.

Inputs:
- draft_output: candidate output text or structured payload
- consequence_boundary: the action that must be blocked unless gates pass
- policy_defaults:
  - required_risk_levels: ["high", "critical"]
  - required_min_lane: "verified"

Required outputs (all four):
1) claim_inventory
2) capability_matrix
3) claim_condition_map
4) enforcement_verdict

Protocol:
1. Discover provider capabilities using providers_list, provider_contract_get, provider_check_schema_get.
2. Extract factual claims from draft_output.
3. Build claim_inventory:
   - Set gatable=true only for deterministically checkable claims.
   - Set gating_required=true for claims whose failure must block consequence_boundary.
   - Include non-empty reason for every gatable=false claim.
4. Build claim_condition_map for all gatable=true claims.
5. Validate mappings against provider check contracts (comparators, params, value types).
6. Run precheck for fast iteration.
7. Before consequence_boundary, run live scenario_start + scenario_next.
8. Set enforcement_verdict.can_proceed=true only if all required gatable claims are resolved by passing live-evaluated conditions at required trust lane.

Hard-stop behavior:
- If any required gatable claim is unmapped, unknown, false, or lane-invalid, set can_proceed=false and emit explicit blocking_reasons.
- Never treat model confidence or self-verification text as evidence.

Embedded JSON Templates

claim_inventory (required)

{
  "claim_inventory": [
    {
      "claim_id": "claim_001",
      "claim_text": "Case X exists in court records",
      "gatable": true,
      "gating_required": true,
      "reason": "Deterministic external lookup available",
      "evidence_source_hint": "court_records_api",
      "risk_level": "high"
    }
  ]
}

capability_matrix (required)

{
  "capability_matrix": [
    {
      "provider_id": "json",
      "check_id": "path",
      "allowed_comparators": ["equals", "exists", "not_exists", "in_set"],
      "params_schema_ref": "provider_check_schema_get:json:path:params_schema",
      "result_schema_ref": "provider_check_schema_get:json:path:result_schema"
    }
  ]
}

claim_condition_map (required)

{
  "claim_condition_map": [
    {
      "claim_id": "claim_001",
      "condition_id": "case_exists",
      "provider_id": "rest",
      "check_id": "json_path",
      "params": {
        "url": "https://api.example.com/cases/lookup?id=925-F3d-1339",
        "jsonpath": "$.exists"
      },
      "comparator": "equals",
      "expected": true,
      "trust_min_lane": "verified"
    }
  ]
}

enforcement_verdict (required)

{
  "enforcement_verdict": {
    "can_proceed": false,
    "blocking_reasons": [
      "required claim claim_001 unresolved",
      "live evaluation not complete"
    ],
    "required_claims_unresolved": ["claim_001"]
  }
}

Minimal Golden Path (One End-to-End Flow)

This flow is intentionally minimal and aligned with current OSS tooling behavior.

Windows tip: PowerShell/CMD do not support bash-style multiline curl. Use a single-line command or PowerShell here-strings. Preset tip: Start with configs/presets/quickstart-dev.toml for local use.

Step 1: Define scenario

curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "scenario_define",
      "arguments": {
        "spec": {
          "scenario_id": "llm-precheck",
          "namespace_id": 1,
          "spec_version": "v1",
          "stages": [
            {
              "stage_id": "main",
              "entry_packets": [],
              "gates": [
                {
                  "gate_id": "quality",
                  "requirement": { "Condition": "report_ok" }
                }
              ],
              "advance_to": { "kind": "terminal" },
              "timeout": null,
              "on_timeout": "fail"
            }
          ],
          "conditions": [
            {
              "condition_id": "report_ok",
              "query": {
                "provider_id": "json",
                "check_id": "path",
                "params": { "file": "report.json", "jsonpath": "$.summary.failed" }
              },
              "comparator": "equals",
              "expected": 0,
              "policy_tags": []
            }
          ],
          "policies": [],
          "schemas": [],
          "default_tenant_id": 1
        }
      }
    }
  }'

Step 2: Register precheck schema

curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "schemas_register",
      "arguments": {
        "record": {
          "tenant_id": 1,
          "namespace_id": 1,
          "schema_id": "llm-precheck",
          "version": "v1",
          "schema": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
              "report_ok": { "type": "number" }
            },
            "required": ["report_ok"]
          },
          "description": "LLM precheck payload schema",
          "created_at": { "kind": "logical", "value": 1 },
          "signing": null
        }
      }
    }
  }'

Step 3: Precheck (fast loop)

curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "precheck",
      "arguments": {
        "tenant_id": 1,
        "namespace_id": 1,
        "scenario_id": "llm-precheck",
        "spec": null,
        "stage_id": "main",
        "data_shape": { "schema_id": "llm-precheck", "version": "v1" },
        "payload": { "report_ok": 0 }
      }
    }
  }'

Expected response shape:

{
  "decision": {
    "kind": "complete",
    "stage_id": "main"
  },
  "gate_evaluations": [
    {
      "gate_id": "quality",
      "status": "true",
      "trace": [
        { "condition_id": "report_ok", "status": "true" }
      ]
    }
  ]
}

Step 4: Live boundary (required before consequential action)

# scenario_start
curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 4,
    "method": "tools/call",
    "params": {
      "name": "scenario_start",
      "arguments": {
        "scenario_id": "llm-precheck",
        "run_config": {
          "tenant_id": 1,
          "namespace_id": 1,
          "run_id": "run-1",
          "scenario_id": "llm-precheck",
          "dispatch_targets": [],
          "policy_tags": []
        },
        "started_at": { "kind": "unix_millis", "value": 1710000000000 },
        "issue_entry_packets": false
      }
    }
  }'

# scenario_next
curl -s http://127.0.0.1:4000/rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 5,
    "method": "tools/call",
    "params": {
      "name": "scenario_next",
      "arguments": {
        "scenario_id": "llm-precheck",
        "request": {
          "run_id": "run-1",
          "tenant_id": 1,
          "namespace_id": 1,
          "trigger_id": "trigger-1",
          "agent_id": "agent-1",
          "time": { "kind": "unix_millis", "value": 1710000000000 },
          "correlation_id": null
        },
        "feedback": "trace"
      }
    }
  }'

Proceed only if the live decision meets your pass policy.

Failure Recovery and Escalation

If validation or evaluation fails:

  1. Capability mismatch
    • Re-query provider_check_schema_get and fix comparator/params/result-type mismatch.
  2. precheck hold or tool error
    • Validate payload against data shape; ensure condition IDs align with payload keys.
  3. Live run hold/fail
    • Inspect runpack (runpack_export) or call evidence_query (if disclosure policy permits).
  4. Trust lane mismatch
    • If policy requires verified, do not approve asserted-only evidence.
  5. Unclear claim classification
    • Escalate to human policy owner; default to gating_required = true for high-risk claims.

Provider-specific deep dives:

Glossary

Claim inventory: Machine-readable list of candidate claims and gating classification. Capability matrix: Provider/check capabilities discovered from DG tools. Claim-condition map: Deterministic mapping from gatable claims to DG conditions. Precheck: Asserted-evidence simulation, no run-state mutation. Live run: Provider-fetched evaluation that mutates run state and supports runpack audit. Consequential action: Any action that changes external state, releases output, or commits a decision.