Overview

Traditional AI compliance relies on retroactive audit logging, which is structurally insufficient for non-deterministic (probabilistic) models. The BiDigest API transitions enterprise risk management to Governance-as-Code by enforcing a strict Machine Handshake at the execution boundary.

This brief outlines the three-stage deployment of the Admissibility Gateway to secure your LLM orchestration layer against Narrative Drift and unauthorized shadow citations.

Phase 1: Anchoring the Ground Truth (Provisioning)

Before API deployment, the enterprise tenant is provisioned by establishing an immutable Ground Truth.

The Anchor: Authorized regulatory identifiers (e.g., SEC REG, FINRA ID, NPI, LEI) are mapped to your verified corporate domain within the BiDigest registry.
The Function: This yields a deterministic, machine-readable dataset — the reference your autonomous agents must verify against before executing a high-risk action.

Phase 2: Routing the Execution Boundary (The Intercept)

The BiDigest API acts as a strict, fail-closed checkpoint for agentic workflows.

The Integration: Route your orchestration layer (LangChain, Copilot Studio, AWS Bedrock, or custom pipelines) through POST /api/v1/admissibility/verify.
The Intercept: Before an agent commits a high-risk action or surfaces synthesized data to an end-user, the payload (context + proposed citations) is evaluated by the Admissibility Gateway.

Phase 3: Machine Handshake & Decision Receipt (Resolution)

At the execution boundary, the gateway evaluates the payload against anchored Ground Truth. Resolution is deterministic — no generative step at this layer.

Outcome A (Approve): When every shadow_citation matches the provisioned allow-list, the API returns 200 OK with admissibility_status: APPROVED and a cryptographic Decision Receipt (compact JWS) binding timestamp, input hash, outcome, and policy result.
Outcome B (Fail-closed): When a citation is not in Ground Truth (Narrative Drift / shadow source), the API returns 403 Forbidden with NARRATIVE_DRIFT_DETECTED and a signed receipt recording the denial — the transaction is severed before unverified liability is incurred.

Request payload (the intercept)

When your agent attempts an action, the orchestration layer posts structured JSON — not a raw chat transcript. The gateway requires the entity anchor, a hash binding to the prompt, and the exact claims and citations pending execution.

entity_anchor — domain + regulatory id (provisioned Ground Truth key).
agent_context — orchestration id, proposed action, prompt_hash.
payload_to_verify — synthesized claims and shadow_citations under verification.

POST/api/v1/admissibility/verify

{
  "entity_anchor": {
    "domain": "client-domain.com",
    "regulatory_id": "SEC-801-12345"
  },
  "agent_context": {
    "orchestration_id": "prod-langchain-01",
    "proposed_action": "transmit_client_advisory",
    "prompt_hash": "a1b2c3d4e5f6g7h8i9j0"
  },
  "payload_to_verify": {
    "synthesized_claims": [
      "Our firm manages $500M in assets.",
      "Performance increased by 12% in Q3."
    ],
    "shadow_citations": [
      "https://client-domain.com/q3-report.pdf",
      "internal_doc_id_9921"
    ]
  }
}

Response payload (evidence while running)

The backend cross-references shadow_citations against the allow-list for that anchor. Matching logic is a deterministic set membership check — no probabilistic scoring at this layer.

Each response includes a decision_receipt.signature: a compact JWS for compliance systems.

POST/api/v1/admissibility/verify200 OK (Admissibility Verified)

{
  "admissibility_status": "APPROVED",
  "reason_code": "GROUND_TRUTH_VERIFIED",
  "decision_receipt": {
    "timestamp": "2026-03-23T10:40:27Z",
    "receipt_id": "rec_pass_1122abc",
    "evidence_hash": "d4e5f6g7h8i9j0a1b2c3",
    "signature": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}

Architecture FAQ: execution & security

1. What is the latency overhead of the Admissibility Gateway?

The Machine Handshake is built for execution-time enforcement. The gateway does not generate tokens or ingest your full context window; it runs a deterministic boolean cross-reference of proposed shadow_citations against indexed Ground Truth. Overhead is typically single-digit milliseconds, comparable to a JWT validation round-trip — bounded by your network and deployment topology.

2. Does the BiDigest API ingest or store proprietary prompts and customer PII?

The contract is structural: regulatory entity identifier, a cryptographic hash of the prompt (to bind the Decision Receipt), and the specific claims and citations attempting to execute. We evaluate the admissibility of the output surface, not your full conversational history, which reduces PII exposure versus log-everything patterns. Final data handling is covered in your enterprise DPA.

3. If the BiDigest API is unavailable, does our AI stack fail closed?

The safe default for unverified generative output is to treat missing admissibility proof as blocking. Your orchestration layer should apply a strict timeout (e.g., 50ms); if no signed Decision Receipt returns in time, route to a deterministic fallback — static approved copy, degraded mode, or human-in-the-loop — so you control uptime without inheriting unverified AI liability.