Cognitive Trust Certificates

Cryptographic proof that a workflow plan has been verified before execution

A Cognitive Trust Certificate (CTC) is issued when the planning engine verifies a multi-step workflow. It proves the plan was checked for correctness, safety, and compliance before any tool ran. After execution, runtime assurances are appended to confirm the plan behaved as expected.

The full formal treatment — including cryptographic architecture, proof structure, and enterprise implications — is in the lab paper: Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems.

What a CTC Proves

Compile-Time Assurances

Before execution begins, the planning engine verifies that the workflow:

  • Terminates – the plan contains no cycles and will complete in finite steps.
  • Is type-safe – every output feeds into a compatible input, with adapters inserted where needed.
  • Complies with policy – no step violates side effect controls, destructive operation rules, or budget limits.
  • Has available credentials – every integration in the plan has valid authentication configured.
  • Consumes all inputs – required data flows through the plan without dangling unused steps.
  • Executes deterministically – given the same inputs, the plan produces the same sequence of operations.

If any check fails, no CTC is issued and the plan does not execute. The system returns a specific explanation of what failed and why.

Runtime Assurances

After execution completes, the CTC is extended with:

  • Execution proof – confirmation that each step ran and returned a result.
  • Budget sufficiency – actual credits consumed stayed within the estimated bounds.
  • Statistical profile – summary of data volumes, latencies, and error rates observed during execution.
  • Drift detection – whether the runtime behavior matched compile-time expectations, or if any step diverged from the plan.

Runtime assurances turn a CTC from a “plan looks correct” proof into a “plan ran correctly” proof.

How CTCs Are Created

CTCs are generated automatically during workflow planning. When you use discovery.plan or flow.into to build a multi-step workflow, the planning engine validates the plan and, if it passes all checks, issues a CTC.

Goal -> Planning Engine -> Validated Plan + CTC

You do not request a CTC explicitly. It is a byproduct of successful planning.

If the plan cannot be verified, you get a structured failure response explaining which checks did not pass.

Skills: Verified Workflows You Can Reuse

A skill is a workflow that has been verified, executed successfully, and saved for reuse. Skills retain their CTC, so they execute without re-verification on subsequent runs.

Creating a Skill

Build a workflow through guided discovery or planning, execute it, and save it:

# Via Guide Mode: complete the workflow, then compile to skill
session = client.guide(goal="sync leads to invoices")
# ... navigate choices ...
skill = client.guide(save_as_skill=True, skill_name="lead_invoice_sync")

Or via the Playground: complete a workflow, then click Save as skill.

Running a Skill

result = client.call_tool("skills@1/lead_invoice_sync@1", {
    "invoice_amount": 1500
})

Skills execute the exact sequence of tools recorded during creation. No re-planning, no re-verification. The CTC from the original run carries forward.

When Skills Re-Verify

If the underlying integrations change (tools added, removed, or schemas updated), the skill’s CTC is invalidated. The next execution triggers re-verification. If the plan still passes all checks, a new CTC is issued transparently. If it fails, you get a clear error explaining what changed.

Cryptographic Integrity

Every CTC is signed with Ed25519 by the DataGrout Certificate Authority (DG CA). The signature covers the certificate’s immutable fields — id, plan hash, assurances, timestamp, and child certificate IDs — so any modification invalidates it. When a workflow produces multiple CTCs (e.g., refraction and charting), the child certificate IDs are included in the parent signature, making the entire chain tamper-evident.

Signatures can be verified with the DG CA public key, available at GET /ca.pem and embedded in the Conduit SDK. See Policy and Security: Cryptographic Signing for full details on the signing architecture.

What a CTC Looks Like

When CTC details are enabled in your Interaction Settings, every tool call response includes a _meta.datagrout.ctc object:

{
  "result": { "workflow_id": "wf_abc123", "status": "completed" },
  "_meta": {
    "datagrout": {
      "ctc": {
        "id": "ctc_7f3a9b2e",
        "viewer_url": "https://datagrout.ai/ctc/ctc_7f3a9b2e",
        "valid": true,
        "assurances": {
          "no_cycles": true,
          "type_safe": true,
          "policy_compliant": true,
          "credentials_available": true,
          "all_inputs_consumed": true,
          "deterministic": false
        },
        "issued_at": "2026-03-09T14:30:00Z",
        "expires_at": "2026-06-07T14:30:00Z",
        "plan_hash": "sha256:e3b0c44298fc1c149afb..."
      },
      "execution_summary": "Completed 3-step workflow. Cost: 4 credits. CTC ctc_7f3a9b2e valid.",
      "receipt": {
        "receipt_id": "rcp_a1b2c3d4",
        "actual_credits": 4,
        "balance_after": 9411
      }
    }
  }
}

deterministic: false here means one step called an external API whose response can vary — the plan is structurally valid, but the output isn’t guaranteed identical across runs. The viewer_url can be shared with anyone (no account required) to inspect the full certificate, assurances, and proof trace.

CTC Viewer

CTCs are shareable. You can generate a viewer link that lets anyone inspect a certificate, including:

  • The workflow steps and their order
  • Which assurances passed at compile time
  • Which runtime assurances were recorded
  • The Ed25519 signature and verification status
  • The timestamp and issuing server

Use the CTC viewer to prove to auditors, customers, or collaborators that a workflow was verified before execution. No account is required to view a shared certificate.

Why CTCs Matter

Without verification: Agents chain tool calls at runtime. If a type mismatch, missing credential, or policy violation exists, you find out when it fails – after partial execution, with side effects already committed.

With CTCs: Every check happens before the first tool runs. If the plan has a CTC, the failure surface is limited to upstream API errors, not planning mistakes.

Use CTCs when:

  • Compliance requires proof that agent workflows were validated before execution.
  • Trust matters – you need to show customers or auditors that an agent did not act arbitrarily.
  • Debugging a failure – the CTC confirms the plan was correct, narrowing the issue to upstream behavior.
  • Reuse – save verified workflows as skills and skip re-verification.

Related