Technical Integration Brief

BiDigest Admissibility API

Deploying the Admissibility Gateway at the orchestration layer — deterministic verification, fail-closed enforcement, and signed Decision Receipts.

Performance supplement — latency & fail-closed enforcement·Print-optimized brief (US Letter → Save as PDF)·After running npm run governance:admissibility-brief-pdf, the file also lives at /downloads/BiDigest_Admissibility_API_Integration_Brief.pdf for Day 6 email attachment.

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. For multi-region deployments, include jurisdiction_context so traffic can bind to the correct SKB partition (e.g. EU vs US policy slices).

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.
jurisdiction_context (optional) — region_code (slug aligned to your routing / SKB partitions, e.g. eu-central) and optional skb_profile_ids for stacked regulatory profiles.

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"
    ]
  },
  "jurisdiction_context": {
    "region_code": "eu-central",
    "skb_profile_ids": ["eu-ai-act"]
  }
}

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..."
  }
}

Technical Supplement: legal question to enforcement evidence

This matrix maps legal scrutiny questions to BiDigest architecture terms and the deterministic evidence each control produces at runtime.

The Legal Question	BiDigest Architectural Term	Technical Enforcement	The Resulting Evidence
1. Who authorized the system to act?	The Machine Handshake	A cryptographic binding of User ID, Model ID, and Tenant Secret at the moment of request.	Attribution: A verifiable signature (JWS) proving the request originated from a licensed and authorized entity.
2. What was it allowed to do in this context?	Ground Truth Anchoring	A deterministic JSON-schema allow-list (Regulatory IDs, URLs, PII boundaries) that replaces passive prompt instructions.	Constraint: A structural record proving the agent was bounded by a pre-defined legal or corporate mandate before generation.
3. What limits were in place during generation?	Narrative Drift Detection	Real-time mathematical comparison between the model’s proposed output and the anchored Ground Truth.	Admissibility: A numeric score (IFQ) demonstrating that the output remained within the tolerated accuracy variance.
4. What evidence ties these limits to the decision?	The Execution Boundary	A hard-coded, fail-closed gateway that intercepts the payload before the commit.	The Decision Receipt: An immutable, signed audit log containing the input hash, policy applied, and drift result.

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.

For a per-component latency table (handshake, Redis/Lua chain check, drift evaluation, JWS receipt) and how this compares to LLM generation time, see the performance supplement.

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.

4. Should legal/compliance teams use the Technical Supplement table as an FAQ shortcut?

Yes. The table is intentionally formatted as a legal-to-technical crosswalk so counsel, security, and engineering can answer core admissibility questions with runtime controls and signed evidence. Keep it on this page and reuse it in legal review packets as a quick reference.

Queue a Forensic Audit for your Domain

Production gateway credentials and tenant provisioning are issued after Ground Truth reconciliation. This audit is the on-ramp for Trustee Tier deployment.