BiDigest Admissibility API: Deployment & Integration Architecture

Subtitle: Establishing execution-time governance and immutable Decision Receipts.

Executive summary

Core thesis. 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.

Phase 1 — Anchoring the Ground Truth (provisioning)

Before API deployment, the tenant is provisioned with an immutable Ground Truth: authorized regulatory identifiers mapped to the verified corporate domain in the BiDigest registry. This yields a deterministic, machine-readable reference that agents verify against before executing high-risk actions.

Phase 2 — Routing the execution boundary (the intercept)

Route your LLM orchestration layer (LangChain, Copilot Studio, AWS Bedrock, or custom pipelines) through POST /api/v1/admissibility/verify. Before an agent commits a high-risk action or surfaces synthesized data, the structured payload is evaluated by the Admissibility Gateway.

Phase 3 — Machine Handshake & Decision Receipt (resolution)

The gateway cross-references proposed shadow_citations against provisioned Ground Truth. Outcomes: 200 OK with APPROVED and a compact JWS Decision Receipt; or 403 Forbidden with NARRATIVE_DRIFT_DETECTED and a signed receipt — fail-closed before unverified liability is incurred.

Payload architecture

Endpoint: POST https://bidigest.com/api/v1/admissibility/verify

Authentication: API key via existing v1 middleware (Authorization: Bearer …).

Request body (example)

{
  "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."
    ],
    "shadow_citations": [
      "https://client-domain.com/q3-report.pdf"
    ]
  }
}

Response — fail-closed (403)

{
  "admissibility_status": "DENIED",
  "reason_code": "NARRATIVE_DRIFT_DETECTED",
  "failed_citations": ["internal_doc_id_9921"],
  "decision_receipt": {
    "timestamp": "2026-03-23T10:40:27Z",
    "receipt_id": "rec_fail_8847xyz",
    "signature": "<compact JWS>"
  }
}

Response — approved (200)

{
  "admissibility_status": "APPROVED",
  "reason_code": "GROUND_TRUTH_VERIFIED",
  "decision_receipt": {
    "timestamp": "2026-03-23T10:40:27Z",
    "receipt_id": "rec_pass_1122abc",
    "evidence_hash": "<sha256>",
    "signature": "<compact JWS>"
  }
}

Integration FAQ & security posture

1. Latency overhead

The gateway does not generate tokens or ingest the full context window; it performs a deterministic allow-list check. Overhead is typically single-digit milliseconds plus network, similar to a JWT validation round-trip.

2. Data privacy / PII

The contract is structural: entity anchor, cryptographic hash of the prompt (receipt binding), and the claims and citations pending execution — not full conversational history. Final handling is covered under your enterprise DPA.

3. Availability & fail-closed behavior

If no signed Decision Receipt returns within your orchestration timeout, route to a deterministic fallback (static approved response, degraded mode, or human-in-the-loop). You control uptime without inheriting unverified generative liability.

Next step

To provision staging and receive API credentials, queue your baseline audit at https://bidigest.com/governance/admissibility-vault/intake

Identity Fidelity Quotient (IFQ), Authority Decay (λ), and Merkle-chained Admissibility Ledger methodologies are patent pending (US Prov. App. No. 63/XXXXX). Unauthorized replication of execution boundary logic is strictly prohibited.