Bidda Verification Methodology (4-Gate Accuracy Pipeline) ========================================================= JS-free text mirror for AI crawlers. Canonical page: https://bidda.com/methodology Last updated: 2026-07-11 HALLUCINATION-REDUCTION STANDARD SOURCE-VERIFIED BY DESIGN HOW WE BUILD TRUSTWORTHY COMPLIANCE INTELLIGENCE Every Bidda node is extracted from a real primary legal source, verified by an 8-point automated script, reviewed by a human, cryptographically signed, and monitored weekly for regulatory amendments. Here is the exact pipeline and why it matters when a regulator asks what your AI was trained on. Primary sources only No inference without a regulatory anchor SHA-256 signed Weekly source monitoring PIPELINE SOURCE VERIFICATION LIVING REGISTRY SOURCE MONITORING SYLVA CODEX SCANNER BENCHMARKS THE PROBLEM WITH AI-GENERATED COMPLIANCE DATA Most AI compliance tools generate plausible-sounding regulatory summaries from training data: a mix of law review articles, blog posts, outdated guidance, and paraphrased summaries, not the actual instruments. When a general-purpose chatbot tells you "GDPR Article 17 requires deletion within 30 days," it is making a confident claim about a regulation it has never read in primary form. The real provision says "without undue delay." That gap is where regulatory liability lives. RESULT: HALLUCINATION AT THE POINT OF COMPLIANCE DECISION THE BIDDA STANDARD Every Bidda compliance node is extracted from the official published text of the regulatory instrument: the actual Act, Regulation, or Standard, not a summary of it. Every claim in the node traces to a specific provision in that text. We do not paraphrase. We do not infer. If a provision cannot be quoted verbatim from the primary source, it does not appear in the node. Uncertainty is marked explicitly and flagged for human review. RESULT: REGULATORY CLAIMS A LAWYER CAN VERIFY AGAINST THE PRIMARY SOURCE GENERATION PIPELINE The Four-Layer Pipeline Every node passes all four layers sequentially. A single failure at any layer means the node is deleted and regenerated, never manually patched. 01 πŸ“„ Primary Source Identification REAL LEGAL INSTRUMENTS ONLY. NO SUMMARIES, NO COMMENTARY Every node begins with a primary legal instrument: an Act of Parliament, an EU Regulation, an ISO standard, an official agency rule. We identify the canonical URL of the official published text: eur-lex.europa.eu, federalregister.gov, legislation.gov.uk. Not a law firm summary, not a news article, not a Wikipedia page. βœ“ Canonical government or standards body URL only βœ“ HTTP 200 verified: dead links blocked before generation βœ“ TLS SPKI fingerprinted weekly for tamper detection βœ“ Instrument reference extracted (Article, Section, Annex) from source text HARD RULE If a regulation cannot be found at a primary legal source with a live, verifiable URL, it is not added to the registry. 02 🧬 AI Extraction: Structured and Constrained FRONTIER-GRADE EXTRACTION. 13-KEY SCHEMA. ZERO INFERENCE PERMITTED. The primary source text is fed to a frontier-class extraction model under a strict prompt constrained to our 13-key schema. The model cannot add, invent, or paraphrase beyond what the source text says. Every threshold, obligation, and timeline must be traceable to a specific clause in the source document. βœ“ Frontier-tier model only: lightweight model classes are permanently blocked because they produce inaccuracies on regulatory text βœ“ Schema enforcement: all 13 keys required, partial outputs are rejected βœ“ No paraphrasing: deterministic workflow steps reproduce source language verbatim βœ“ Placeholder markers forbidden: every workflow step is real regulatory procedure βœ“ Em dashes and vague language auto-blocked at generation time HARD RULE Lightweight model classes are permanently disqualified from our pipeline. We benchmarked them against frontier-tier extraction on the same source set and they failed at a rate that no human-review process can rescue. 03 πŸ”¬ Automated Layer 1 Verification EIGHT-POINT AUTOMATED REVIEW. ZERO FAIL TOLERANCE BEFORE ACCEPTANCE. Every extracted node passes through our proprietary Layer 1 verifier before it can be considered for acceptance into the registry. The verifier performs eight independent checks against the primary source. A single FAIL verdict means the node is deleted and regenerated, never manually patched. βœ“ Source URL resolves with HTTP 200: no redirects, no paywalls, no bot blocks βœ“ Section references present in citations and verifiable in source text βœ“ Threshold values (fines, timelines, percentages) traced to specific clauses βœ“ Dependency IDs resolve to real nodes already in the registry βœ“ Integrity hash format valid: SHA-256, 64 hex chars βœ“ Domain maps to one of the canonical sovereign pillars βœ“ Banned workflow patterns absent: auto-FAIL on placeholder markers or critical-flaw tags in any step action, condition, or fallback field βœ“ Em dashes absent from workflow content: auto-FAIL if present HARD RULE Zero FAIL is the only acceptable outcome. A node with one FAIL verdict across eight checks is deleted in full. 04 πŸ‘ Layer 2 Human Review EVERY WARN NODE REVIEWED BY A HUMAN AGAINST THE LIVE SOURCE DOCUMENT. Nodes that pass Layer 1 with warnings (ambiguous section references, bot-blocked source URLs, borderline threshold values) go to Layer 2. A human reviewer uses WebFetch to pull the live source document and verifies each flagged claim against the actual regulatory text. Confirmed errors mean deletion and regeneration. βœ“ WebFetch against live source URL: not cached, not summarised βœ“ Flagged claim verified in the source text character by character βœ“ Wrong section numbers, wrong thresholds, cross-jurisdiction contamination = delete βœ“ Accepted nodes move to golden registry: the permanent, immutable source of truth βœ“ Accepted nodes integrity-rehashed (SHA-256) and re-validated before any build HARD RULE Legal-Grade Standard: before accepting any node, we ask: would a legal team accept this as accurate against the primary source? If uncertain, the node is deleted. Quality over speed. Always. FOR COMPLIANCE OFFICERS What "Source Verified" Actually Means When we say a node is source-verified, we mean every piece of guidance it contains can be traced directly back to the document it was drawn from (the original regulation, ISO standard, or official framework), not a summary, not a blog post, not a second-hand interpretation. πŸ“„ PRIMARY SOURCES ONLY Every node in the Bidda registry is built from the official, published version of the regulation. NIST publications, EU Official Journal, ISO/IEC standards, ICAO annexes, and equivalent authority bodies. We never use third-party commentaries or paraphrased guides as source material. If you quote a Bidda node in an audit submission, you can point directly to the regulation it came from. The citation is embedded in the node itself. πŸ”’ CRYPTOGRAPHIC INTEGRITY Each node is assigned a SHA-256 hash, a unique digital fingerprint of that node's content at the moment it was verified. If anyone changes even a single character of the node's data after signing, the fingerprint no longer matches and the system flags it immediately. You can be confident the compliance guidance you receive is exactly what was reviewed and approved, not a version that has been edited, corrupted, or tampered with in transit. πŸ“… DATED & VERSION-CONTROLLED Regulations change. Nodes carry a version number and a last_updated date. When the underlying regulation is amended, the affected nodes are re-audited and re-signed, and the version number increments. You always know whether you are looking at current law. Your compliance team is never inadvertently working from an outdated framework, one of the most common causes of audit findings. πŸ”— CROSS-FRAMEWORK MAPPING Most organisations operate under multiple overlapping standards: GDPR and ISO 27001, or HIPAA and SOC 2. Each node includes a crosswalks field that maps the regulation to related frameworks. Satisfying one standard often partially satisfies another, and the nodes tell you where. You can see exactly which controls from Framework A satisfy requirements in Framework B, reducing duplicated compliance effort across your organisation. THE BOTTOM LINE FOR COMPLIANCE OFFICERS Bidda does not produce advice. It surfaces verified, primary-source regulatory logic in a structured format that compliance teams can act on, cite, and present to auditors. Every claim has a source. Every source is documented. Every document is dated. That is what source-verified means in practice. CONTINUOUS INTEGRITY After Acceptance: The Living Registry Acceptance into the golden registry is not the end of the quality process. It is the beginning of a continuous integrity programme. CURRENT IMMUTABLE STATUS LEDGER CRYPTOGRAPHICALLY HARDENED VERIFIED NODES 10,085 ZERO-TRUST FAILURES 0.00% INTEGRITY HASH SHA-256 DATA PROVENANCE OFFICIAL SYSTEM NOTE: Autonomous agents can verify node integrity by comparing their local cryptographic payload hash against our publicly signed index. This is designed to detect man-in-the-middle tampering, silent data changes, and injected logic. πŸ” Integrity Hash Every node gets a SHA-256 content hash at acceptance. The hash is re-verified on every build. Any change to node content invalidates the hash and blocks deployment. πŸ“‘ Weekly Source Watch Every source URL is re-fetched weekly. TLS public-key hash detects DNS hijacking. Content SHA-256 detects substantive amendments by the regulator. Changes queue for human review within seven days. β›“ Git Merkle Chain Every version of every node is preserved in the git commit history. The DAG structure provides cryptographic chaining, independently verifiable with stock git tooling. No proprietary audit system required. WEEKLY AUTOMATED MONITORING Knowing When Regulations Change Knowing a node is accurate today is only half the picture. Knowing it is still accurate next week is the other half. Bidda runs an automated scan of every primary source URL across all 10,085 nodes every week, before any compliance team would typically notice an amendment themselves. πŸ” TLS CERTIFICATE FINGERPRINT Each primary source URL is fingerprinted at the TLS layer, the cryptographic key of the server hosting the regulation. If a regulatory body's server key changes unexpectedly, the mismatch is flagged for human review before any change enters the registry. Catches: DNS hijacking, certificate swaps, MITM redirects on regulatory domains. πŸ“ CONTENT HASH COMPARISON A SHA-256 hash of the published source text is compared against the baseline from last verification. If the text changes, even a single amended clause, the hash no longer matches, and the affected node enters the amendment review queue within 7 days. Catches: published amendments, revised annexes, superseded standards, regulation repeals. πŸ“‹ GIT MERKLE AUDIT TRAIL Every weekly scan result is committed to a public git repository. Each commit is a Merkle-anchored snapshot of what every source looked like at a specific point in time, verifiable with standard open-source tooling. Useful for: regulatory audits, evidence of due diligence, litigation support. LIVE REGISTRY HEALTH: PUBLIC ENDPOINT Compliance teams and agents can query this public endpoint at any time, with no authentication required, to see the current state of the source integrity scan. If sources_with_changes_in_last_7_days is non-zero, re-run staleness checks against your cached node inventory to identify which regulations have been amended. REQUEST curl https://bidda.com/api/v1/registry-health.json KEY FIELDS TO WATCH last_check_completed: when the most recent scan ran sources_with_changes_in_last_7_days: non-zero = action needed next_scheduled_check: every Monday 02:00 UTC integrity_attestation: cryptographic proof string for audit logs Recommended practice: add this endpoint to your weekly compliance checklist. One call tells you whether any regulation you rely on has been amended since your last review. VIEW LIVE β†’ INTERACTIVE VISUAL TOOL Sylva Codex: The Regulation Dependency Graph One of the most overlooked risks in enterprise compliance is treating regulations as silos: GDPR here, ISO 27001 there, DORA somewhere else. In practice, regulations overlap, depend on each other, and share control requirements. The Sylva Codex makes those relationships visible and machine-traversable. πŸ•ΈοΈ WHAT IT IS An interactive network graph rendering every verified Bidda node as a point in a live dependency topology. Each edge represents a real, documented relationship between two regulations: a prerequisite, a crosswalk, or a control overlap confirmed by primary source analysis. Updates automatically as new nodes are accepted. πŸ” WHAT IT SHOWS YOU Click any regulation and the graph highlights its full dependency chain in gold: what it depends on, what depends on it, and which peer frameworks address the same control obligations. Example: click the EU AI Act node to see immediately how it draws from GDPR Article 22, ISO/IEC 42001, and NIST AI RMF. πŸ—ΊοΈ CROSS-FRAMEWORK OVERLAP ANALYSIS Most organisations operating under multiple overlapping standards (GDPR and ISO 27001, or HIPAA and SOC 2, or DORA and NIS2) spend significant audit effort duplicating control evidence. The Sylva Codex surfaces shared control obligations so your team can identify which evidence already satisfies multiple requirements simultaneously. πŸ€– AGENT-TRAVERSABLE DEPENDENCY GRAPH For AI compliance systems, the Sylva Codex is not just a visual. It is the structural backbone of the entire registry. Every node's dependencies[] array is a machine-readable edge list that autonomous agents can traverse programmatically, resolving a compliance question without a human directing each step. 10,085 REGULATION NODES IN GRAPH 39 SOVEREIGN PILLARS VISUALISED 2,400+ DEPENDENCY EDGES MAPPED THE BOTTOM LINE The Sylva Codex answers the question every compliance officer eventually faces: "If this regulation changes, what else in our programme is affected?" It turns a historically manual, expensive analysis into a visual query that takes seconds. OPEN SYLVA CODEX β†’ FREE DEVELOPER TOOL, OPEN SOURCE Bidda Agent Compliance Scanner A free, open-source GitHub Action that brings Bidda's sovereign compliance intelligence directly into your engineering workflow, scanning every pull request for AI agent regulatory exposure before it reaches production. πŸ” WHAT IT SCANS On every pull request, the Action scans changed files for AI agent code patterns with direct regulatory implications: LangChain, CrewAI, AutoGen, Pydantic AI imports; MCP tool and server definitions; biometric identification libraries (EU AI Act Annex III); AI-driven hiring code (NYC Local Law 144); automated credit-decisioning (GDPR Article 22, ECOA); and DORA-relevant ICT third-party dependencies. πŸ’¬ WHAT YOUR TEAM GETS A single, idempotent PR comment, updated on each push, never spamming the thread. Each matched pattern links to the specific Bidda node most relevant to that code path, with the BLUF summary, free discovery metadata, and a vault unlock link for the full deterministic compliance workflow at $0.01 USDC. πŸ”’ PRIVACY & DATA FLOW The scanner runs entirely on your GitHub-hosted runner. Pattern matching is local. Your code, prompts, and diffs never leave your environment. Only the detected pattern ID and a domain filter are used to query Bidda's public discovery API, which requires no authentication. πŸ’‘ ADVISORY, NEVER BLOCKING Advisory only by default. The action never blocks a PR. Compliance officers get the right reference at the right moment; engineers keep shipping without friction. Enterprise v0.2 adds Skyfire bearer token support for bulk pre-authorised unlocks. ADD IT IN 30 SECONDS Zero config. No API key. No account required. VIEW SOURCE β†’ # .github/workflows/bidda-compliance.yml name: Bidda Agent Compliance on: pull_request: branches: [main] permissions: pull-requests: write contents: read jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: Bidda-Ai/agent-compliance-scanner@v0 10,085 NODES IN REGISTRY 12 CODE PATTERNS DETECTED $0.01 PER FULL NODE UNLOCK 0 PR BLOCKS BY DEFAULT ILLUSTRATIVE WORKFLOW How a Real Agent Uses Bidda A global logistics platform deploys an autonomous shipping agent that needs to verify compliance rules for shipping lithium batteries by air, without calling a human compliance officer. Here is how Bidda handles it end-to-end in four deterministic steps. QUERY AGENT Discovery Request A logistics agent handling an international shipment queries the Sovereign Registry for IATA Dangerous Goods Regulations applicable to lithium battery air transport. GET /api/v1/nodes/iata-dgr-lithium-batteries RETURN BIDDA Verified Node Metadata Bidda returns the verified node BLUF, canonical authority citation, SHA-256 integrity hash, and a 402 challenge to unlock the full deterministic logic graph. { "id": "iata-dgr-9a", "hash": "a3f9...c12e", "authority": "IATA", "requires_payment": true } SETTLE AGENT L402 Micropayment The agent autonomously settles a $0.01 USDC transaction on the Base network. The signed on-chain receipt is presented as the vault bearer token. Authorization: L402 [base_signed_onchain_receipt] UNLOCK BIDDA Full Intelligence Delivered The complete deterministic logic graph is returned: packing rules, quantity limits, labelling requirements, and documentation checklists, all machine-executable, with reduced hallucination risk. { "rules": [...], "documentation": [...], "verified_at": "2026-04", "hash_valid": true } THE OUTCOME The agent autonomously resolved what would have taken a human compliance analyst 2 to 4 hours to validate: the correct IATA Section II lithium battery packing regulations, verified against the official 2024 IATA DGR edition, cryptographically signed, and injected directly into the shipment workflow, in under 400 milliseconds. Reduced hallucination risk. No liability gap. No human bottleneck. Current Quality Benchmarks Snapshot of registry health at last build. Re-published with every deploy. 10,085 NODES ACCEPTED all 4 layers passed 0 CRITICAL VIOLATIONS in current registry 39 SOVEREIGN PILLARS zero empty ~7 AVG PRIMARY CITATIONS per node 0 PLACEHOLDER MARKERS eliminated April 2026 7,700+ SOURCE URLS fingerprinted weekly What This Means in Practice COMPLIANCE OFFICERS & LEGAL TEAMS β†’ Every node is traceable to a specific clause in a specific instrument. Paste the citation into eur-lex.europa.eu or federalregister.gov and read it yourself. β†’ The version of the source at extraction time is fingerprinted. You can prove what the regulation said on the date your AI agent consulted it. β†’ Zero placeholder content in production: every workflow step is a real regulatory procedure, not a gap marker. AI AGENTS & AUTONOMOUS SYSTEMS β†’ The deterministic_workflow in each node is a machine-executable procedure, not a natural language summary but a structured sequence of conditional steps. β†’ The actionable_schema provides typed fields for agent orchestration: trigger conditions, required inputs, decision thresholds, output format. β†’ The dependency graph lets an agent discover the full compliance chain for any obligation, from a single node unlock to a complete regulatory mapping. Frequently Asked Questions How does Bidda verify compliance nodes? + What does "source-verified" mean for a compliance node? + How does Bidda detect when a regulation changes? + What is the Sylva Codex and how does it help compliance officers? + Can I use Bidda nodes in an audit or legal proceeding? + Why are lightweight AI models forbidden from this pipeline? + See It For Yourself: Free Sample Node The free sample node for EU AI Act Article 10 shows every field of the 13-key schema: the full deterministic workflow, all primary citations, the actionable schema, and the dependency graph. No payment required. VIEW FREE SAMPLE NODE β†’ BROWSE 10,085 NODES β†’ Enterprise inquiry: info@bidda.com Β· API access: api@bidda.com