{
  "schema": "varexis-question-context-router/0.2",
  "generated_at_utc": "2026-10-06T23:36:13Z",
  "principle": "The context of the question is part of the answer contract.",
  "routing_rule": "Variable and near questions may route to evidence records, but answers must remain bounded by the validated claim boundary.",
  "contexts": [
    {
      "context_id": "reduce_compute_sensor_workloads",
      "plain_language_trigger": "How can expensive compute on mostly quiet telemetry be reduced without losing important events?",
      "near_questions": [
        "How do we reduce GPU cost for anomaly detection?",
        "Can we skip quiet telemetry?",
        "Can heavy spectral analysis be gated?",
        "Can we avoid processing every partition?",
        "Is there evidence for selective execution on sensor data?",
        "Has BDAS been tested on pump data?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1",
        "VXI-BDAS-20261001-PUMP-E1-CHALLENGED-NEGATIVE-v1",
        "VXI-BDAS-202608-M1-QUALIFICATION-AURIC-MONITOR-v1",
        "VXI-BDAS-20260912-S1-SPECTRAL-CPU-REPLAY-v1"
      ],
      "default_answer_boundary": "Evidence is workload-specific. Do not generalise without matching validation."
    },
    {
      "context_id": "safe_refusal_and_not_qualified_evidence",
      "plain_language_trigger": "Which VAREXIS/BDAS records show refusal, non-promotion, or not-qualified outcomes?",
      "near_questions": [
        "Did BDAS refuse unsafe promotion?",
        "Which runs failed economics?",
        "Are negative results preserved?",
        "Can correctness pass while ROI fails?",
        "Which records are safe but not performance qualified?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20260504-M3-EXTERNAL-LOCKED-SAFE-REFUSAL-v1",
        "VXI-BDAS-20260913-NASA-IMS-E4-1-SAFE-NOT-PERFORMANCE-v1",
        "VXI-BDAS-20261002-7026446-CORRECTNESS-NOT-ECONOMICS-v1",
        "VXI-BDAS-20260915-QV1-PCB1-VISION-CORRECTNESS-NOT-ECONOMICS-v1",
        "VXI-BDAS-20260919-CK4A-CAPTURE-NO-PROMOTION-v1"
      ],
      "default_answer_boundary": "Return the refusal or non-qualified state. Do not convert negative evidence into a performance or deployment claim."
    },
    {
      "context_id": "index_corpus_and_ledger_evidence",
      "plain_language_trigger": "What evidence exists that VAREXIS-INDEX has a corpus and ledgered records?",
      "near_questions": [
        "How many records are in the public index?",
        "Was an INDEX corpus tranche recovered?",
        "Is there a ledger bridge?",
        "Were candidate records staged?",
        "What is public versus paid?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20261004-LEDGER-0042-CANONICAL-FREEZE-BUNDLE-v1",
        "VXI-BDAS-20261004-7001071-INDEX-CORPUS-TRANCHE-v1",
        "VXI-BDAS-20261002-7026447-CANDIDATE-BATCH-SUMMARY-v1"
      ],
      "default_answer_boundary": "Public records show summary existence and boundaries. Fuller evidence-route metadata belongs to paid/manual access."
    },
    {
      "context_id": "developer_paid_access_discovery",
      "plain_language_trigger": "What can agents inspect for free, and what requires paid VAREXIS-INDEX access?",
      "near_questions": [
        "Can an agent inspect VAREXIS-INDEX before paying?",
        "What does Developer/API access add?",
        "What does a single request buy?",
        "What does an evidence receipt contain?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1",
        "VXI-BDAS-20261004-LEDGER-0042-CANONICAL-FREEZE-BUNDLE-v1",
        "VXI-BDAS-20261004-7001071-INDEX-CORPUS-TRANCHE-v1",
        "VXI-BDAS-20261002-7026447-CANDIDATE-BATCH-SUMMARY-v1",
        "VXI-BDAS-20261001-PUMP-E1-CHALLENGED-NEGATIVE-v1",
        "VXI-BDAS-20260913-NASA-IMS-E4-1-SAFE-NOT-PERFORMANCE-v1",
        "VXI-BDAS-202608-M1-QUALIFICATION-AURIC-MONITOR-v1",
        "VXI-BDAS-20260504-M3-EXTERNAL-LOCKED-SAFE-REFUSAL-v1",
        "VXI-BDAS-20261002-7026446-CORRECTNESS-NOT-ECONOMICS-v1",
        "VXI-BDAS-20260915-QV1-PCB1-VISION-CORRECTNESS-NOT-ECONOMICS-v1",
        "VXI-BDAS-20260919-CK4A-CAPTURE-NO-PROMOTION-v1",
        "VXI-BDAS-20260912-S1-SPECTRAL-CPU-REPLAY-v1",
        "VXI-BDAS-202604-H1-3-LOCKED-SEED-VALIDATION-v1",
        "VXI-BDAS-202604-H2-1-HYDRAULIC-PUMP-SAFE-NOT-SELECTIVE-v1",
        "VXI-BDAS-202604-I1-DEVELOPMENT-PASS-v1",
        "VXI-BDAS-202604-I2-HOLDOUT-RESERVED-HASHED-v1",
        "VXI-BDAS-202604-STAGE-B-CONTROLLED-REDUCTION-v1",
        "VXI-BDAS-202604-STAGE-FG-SAFE-NOT-SELECTIVE-v1",
        "VXI-BDAS-202606-IIOT-SYNTHETIC-60M-LOGS-v1",
        "VXI-BDAS-202606-163M-ROW-PUBLIC-REDUCTION-v1",
        "VXI-BDAS-20260912-CENTERED-LIVE-PROBE-V1-v1",
        "VXI-BDAS-20260912-FUSED-ATTRIBUTION-V2-v1",
        "VXI-BDAS-20260912-PERSISTENT-OUTPUT-V3-v1",
        "VXI-BDAS-20260912-DECODER-V4-v1",
        "VXI-BDAS-20260912-CONSUMER-BINDING-V1-v1",
        "VXI-BDAS-20260913-G5-2-LOCKED-SYNTHETIC-CONFIRMATION-v1",
        "VXI-BDAS-20260915-OT3-FREQUENCY-LOCALIZED-v1",
        "VXI-BDAS-20260915-C1-PUMP-LOCKED-OUTER-v1",
        "VXI-BDAS-20260915-C3-INFO-GEOMETRY-DEV-v1",
        "VXI-BDAS-20260915-C4-MACHINE-LOCAL-CALIBRATION-v1",
        "VXI-BDAS-202608-M4-MANUFACTURING-EXTERNAL-PROTOCOL-v1",
        "VXI-BDAS-20260912-S1-SPECTRAL-ALARM-REFERENCE-v1",
        "VXI-BOUNDARY-PUMP-E2C-FRESH-HOLDOUT-BOUNDARY-v1",
        "VXI-BOUNDARY-PUMP-E2C-CUSTOMER-SAVINGS-BOUNDARY-v1",
        "VXI-BOUNDARY-LEDGER-0042-DEPLOYMENT-BOUNDARY-v1",
        "VXI-BOUNDARY-CANDIDATE-BATCH-CANONICAL-STATUS-BOUNDARY-v1",
        "VXI-BOUNDARY-PUMP-E1-PROMOTION-BOUNDARY-v1",
        "VXI-BOUNDARY-NASA-IMS-PERFORMANCE-BOUNDARY-v1",
        "VXI-BOUNDARY-M3-QUALIFICATION-PROMOTION-BOUNDARY-v1",
        "VXI-BOUNDARY-CORRECTNESS-ECONOMIC-GAIN-BOUNDARY-v1",
        "VXI-BOUNDARY-QV1-PCB1-NET-ECONOMICS-BOUNDARY-v1",
        "VXI-BOUNDARY-CK4A-CAPTURE-PROMOTION-BOUNDARY-v1",
        "VXI-BOUNDARY-S1-REPLAY-ALARM-BOUNDARY-v1",
        "VXI-BOUNDARY-H1-3-GENERALISATION-BOUNDARY-v1",
        "VXI-BOUNDARY-H2-1-PUMP-DIAGNOSTICS-BOUNDARY-v1",
        "VXI-BOUNDARY-I2-RESERVATION-PERFORMANCE-BOUNDARY-v1",
        "VXI-BOUNDARY-STAGE-B-GENERAL-ACCELERATION-BOUNDARY-v1",
        "VXI-BOUNDARY-IIOT-SYNTHETIC-CUSTOMER-VALIDATION-BOUNDARY-v1",
        "VXI-BOUNDARY-PUBLIC-ROW-SCALE-APPLICABILITY-BOUNDARY-v1",
        "VXI-BOUNDARY-LIVE-PROBE-PUBLIC-API-BOUNDARY-v1",
        "VXI-BOUNDARY-ATTRIBUTION-CLAIM-TRUTH-BOUNDARY-v1",
        "VXI-BOUNDARY-CONSUMER-BINDING-RUNTIME-BOUNDARY-v1",
        "VXI-BOUNDARY-CORPUS-RECOVERY-PERFORMANCE-BOUNDARY-v1",
        "VXI-BOUNDARY-M1-WORKLOAD-QUALIFICATION-BOUNDARY-v1",
        "VXI-BOUNDARY-I1-INDEPENDENT-REPLICATION-BOUNDARY-v1",
        "VXI-BOUNDARY-STAGE-FG-SELECTIVITY-BOUNDARY-v1",
        "VXI-BOUNDARY-PERSISTENCE-CLAIM-TRUTH-BOUNDARY-v1",
        "VXI-BOUNDARY-DECODER-V4-ACCELERATION-BOUNDARY-v1",
        "VXI-BOUNDARY-G5-2-REAL-WORLD-PERFORMANCE-BOUNDARY-v1",
        "VXI-BOUNDARY-OT3-WORKLOAD-REDUCTION-BOUNDARY-v1",
        "VXI-BOUNDARY-C1-PUMP-DIAGNOSTIC-SCOPE-BOUNDARY-v1",
        "VXI-BOUNDARY-C3-QUALIFICATION-PROMOTION-BOUNDARY-v1",
        "VXI-BOUNDARY-C4-PERFORMANCE-IMPROVEMENT-BOUNDARY-v1",
        "VXI-BOUNDARY-M4-PROTOCOL-PERFORMANCE-BOUNDARY-v1",
        "VXI-BOUNDARY-S1-REFERENCE-CERTIFICATION-BOUNDARY-v1",
        "VXI-BOUNDARY-PUMP-E2C-HARDWARE-CONTRACT-BOUNDARY-v1",
        "VXI-BOUNDARY-PUMP-E2C-RECONSTRUCTION-BOUNDARY-v1",
        "VXI-BOUNDARY-CANDIDATE-BATCH-PUBLICATION-BOUNDARY-v1",
        "VXI-BOUNDARY-CORRECTNESS-OUTER-HOLDOUT-BOUNDARY-v1",
        "VXI-BOUNDARY-CK4A-HOLDOUT-ACCESS-BOUNDARY-v1",
        "VXI-BOUNDARY-ATTRIBUTION-PRIVATE-SOURCE-BOUNDARY-v1",
        "VXI-BOUNDARY-H1-3-MECHANISM-DISCLOSURE-BOUNDARY-v1",
        "VXI-EXT-A2A-100-02-v1",
        "VXI-EXT-A2A-100-03-v1",
        "VXI-EXT-A2A-100-04-v1",
        "VXI-EXT-OPA-01-v1",
        "VXI-EXT-OPA-02-v1",
        "VXI-EXT-OPA-03-v1",
        "VXI-EXT-OPA-04-v1",
        "VXI-EXT-SPIFFE-01-v1",
        "VXI-EXT-SPIFFE-02-v1",
        "VXI-EXT-SPIFFE-03-v1",
        "VXI-EXT-SPIFFE-04-v1",
        "VXI-EXT-SPIFFE-05-v1",
        "VXI-EXT-GVISOR-01-v1",
        "VXI-EXT-GVISOR-02-v1",
        "VXI-EXT-GVISOR-03-v1",
        "VXI-EXT-GVISOR-04-v1",
        "VXI-EXT-SLSA-12-PROV-01-v1",
        "VXI-EXT-SLSA-12-TRACK-01-v1",
        "VXI-EXT-SLSA-12-03-v1",
        "VXI-EXT-SIGSTORE-01-v1",
        "VXI-EXT-SIGSTORE-02-v1",
        "VXI-EXT-SIGSTORE-03-v1",
        "VXI-EXT-SIGSTORE-BUNDLE-01-v1",
        "VXI-EXT-OTEL-SEMCONV-01-v1",
        "VXI-BDAS-20260902-N1-6256446-WIND-SCADA-PORTFOLIO-SAFE-REFUSAL-v1",
        "VXI-BDAS-20260824-M4B-6111326-CENTRIFUGE-EXTERNAL-SAFE-REFUSAL-v1",
        "VXI-BDAS-20260824-OBS-M4B-001-PROSPECTIVE-QUALIFICATION-SCORE-v1",
        "VXI-BDAS-20260821-M4-6080185-MANUFACTURING-EXTERNAL-SAFE-REFUSAL-v1",
        "VXI-BDAS-BACKBLAZE-D0-7135082-DEVELOPMENT-v1",
        "VXI-BDAS-BACKBLAZE-D1-7135360-WORKER-FAILED-v1",
        "VXI-EXT-CEDAR-01-v1",
        "VXI-EXT-CEDAR-02-v1",
        "VXI-EXT-CEDAR-03-v1",
        "VXI-EXT-CEDAR-04-v1",
        "VXI-EXT-CVSS-40-01-v1",
        "VXI-EXT-CVSS-40-02-v1",
        "VXI-EXT-CVSS-40-04-v1",
        "VXI-EXT-OSV-API-01-v1",
        "VXI-EXT-OSV-API-03-v1",
        "VXI-EXT-OSV-API-04-v1",
        "VXI-EXT-OSV-06-v1",
        "VXI-EXT-SPDX-30-02-v1",
        "VXI-EXT-OPENSSF-SCORECARD-01-v1",
        "VXI-EXT-RFC9700-01-v1",
        "VXI-EXT-RFC9700-02-v1",
        "VXI-EXT-RFC9700-03-v1",
        "VXI-EXT-RFC9700-04-v1",
        "VXI-EXT-CYCLONEDX-17-01-v1",
        "VXI-EXT-CYCLONEDX-17-02-v1",
        "VXI-EXT-CDX-17-05-v1"
      ],
      "default_answer_boundary": "Public discovery is free. Paid access starts bounded request handling, evidence receipts, exports, or launch-phase Developer/API onboarding."
    },
    {
      "context_id": "positive_selective_execution_evidence",
      "plain_language_trigger": "Which BDAS records support bounded selective execution or workload reduction interest?",
      "near_questions": [
        "Which records show positive selective execution evidence?",
        "Which records show reduction but not production readiness?",
        "Can I see positive and bounded BDAS evidence?",
        "What records support compute-reduction interest?"
      ],
      "routes_to_records": [
        "VXI-BDAS-202604-H1-3-LOCKED-SEED-VALIDATION-v1",
        "VXI-BDAS-202604-STAGE-B-CONTROLLED-REDUCTION-v1",
        "VXI-BDAS-202606-IIOT-SYNTHETIC-60M-LOGS-v1",
        "VXI-BDAS-202606-163M-ROW-PUBLIC-REDUCTION-v1",
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1",
        "VXI-BDAS-20260915-C1-PUMP-LOCKED-OUTER-v1"
      ],
      "default_answer_boundary": "Return bounded positive evidence and explicitly state missing production, savings, generalisation or deployment claims."
    },
    {
      "context_id": "negative_and_non_promoted_development",
      "plain_language_trigger": "Which records show safe, challenged, not promising, or non-promoted evidence?",
      "near_questions": [
        "Which BDAS runs were not promoted?",
        "Which records show negative evidence?",
        "Can failed economics still be useful?",
        "Which records should refuse overclaiming?"
      ],
      "routes_to_records": [
        "VXI-BDAS-202604-H2-1-HYDRAULIC-PUMP-SAFE-NOT-SELECTIVE-v1",
        "VXI-BDAS-202604-STAGE-FG-SAFE-NOT-SELECTIVE-v1",
        "VXI-BDAS-20260915-OT3-FREQUENCY-LOCALIZED-v1",
        "VXI-BDAS-20260915-C3-INFO-GEOMETRY-DEV-v1",
        "VXI-BDAS-20260915-C4-MACHINE-LOCAL-CALIBRATION-v1",
        "VXI-BDAS-20261002-7026446-CORRECTNESS-NOT-ECONOMICS-v1",
        "VXI-BDAS-20261001-PUMP-E1-CHALLENGED-NEGATIVE-v1"
      ],
      "default_answer_boundary": "Return non-promotion or negative state. Do not convert it into a success claim."
    },
    {
      "context_id": "pipeline_validation_and_contract_binding",
      "plain_language_trigger": "Which records show pipeline, attribution, output, decoder or consumer-contract discipline?",
      "near_questions": [
        "Which records support pipeline confidence?",
        "Which records show evidence binding and attribution?",
        "Which records support developer onboarding?",
        "Which records show checks without claiming performance?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20260912-CENTERED-LIVE-PROBE-V1-v1",
        "VXI-BDAS-20260912-FUSED-ATTRIBUTION-V2-v1",
        "VXI-BDAS-20260912-PERSISTENT-OUTPUT-V3-v1",
        "VXI-BDAS-20260912-DECODER-V4-v1",
        "VXI-BDAS-20260912-CONSUMER-BINDING-V1-v1",
        "VXI-BDAS-20261004-LEDGER-0042-CANONICAL-FREEZE-BUNDLE-v1"
      ],
      "default_answer_boundary": "Return interface or pipeline discipline only. Do not infer performance, truth or deployment authority."
    },
    {
      "context_id": "external_protocol_and_holdout_discipline",
      "plain_language_trigger": "Which records show external protocol, holdout control, or evaluation discipline?",
      "near_questions": [
        "Which records show holdout discipline?",
        "Which records show protocol-before-scoring discipline?",
        "Which external records were safe but not qualified?",
        "Which records protect against post-hoc claims?"
      ],
      "routes_to_records": [
        "VXI-BDAS-202604-I2-HOLDOUT-RESERVED-HASHED-v1",
        "VXI-BDAS-202608-M4-MANUFACTURING-EXTERNAL-PROTOCOL-v1",
        "VXI-BDAS-20260913-NASA-IMS-E4-1-SAFE-NOT-PERFORMANCE-v1",
        "VXI-BDAS-20260504-M3-EXTERNAL-LOCKED-SAFE-REFUSAL-v1"
      ],
      "default_answer_boundary": "Return protocol and holdout discipline. Do not state performance success unless separately evidenced."
    },
    {
      "context_id": "boundary_pump_e2c_fresh_holdout_boundary",
      "plain_language_trigger": "Can PUMP-E2C be cited as a fresh holdout result?",
      "near_questions": [
        "Is the PUMP-E2C evidence from an untouched holdout?",
        "Can I describe PUMP-E2C as a blind test?",
        "Does consumed PUMP-E2C evidence establish fresh validation?",
        "Which PUMP-E2C claim excludes new holdout performance?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-PUMP-E2C-FRESH-HOLDOUT-BOUNDARY-v1",
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1"
      ],
      "default_answer_boundary": "PUMP-E2C is published as historically consumed engineering evidence. Its public source explicitly excludes fresh holdout validation. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_pump_e2c_customer_savings_boundary",
      "plain_language_trigger": "Can a buyer infer customer savings from PUMP-E2C?",
      "near_questions": [
        "Can PUMP-E2C justify a customer ROI figure?",
        "Does PUMP-E2C demonstrate a reduction in a buyer's bill?",
        "Can PUMP-E2C evidence be used to promise operating savings?",
        "Does PUMP-E2C establish a commercial payback period?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-PUMP-E2C-CUSTOMER-SAVINGS-BOUNDARY-v1",
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1"
      ],
      "default_answer_boundary": "The public PUMP-E2C record supports a narrow selective-execution claim on consumed evidence. It lists customer savings as not demonstrated. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_ledger_0042_deployment_boundary",
      "plain_language_trigger": "Does Ledger 0042 establish production deployment?",
      "near_questions": [
        "Can a Ledger 0042 freeze be used as deployment evidence?",
        "Does the Ledger 0042 bundle prove that a service is live?",
        "Can a canonical ledger entry authorise production use?",
        "What deployment limitation belongs in a Ledger 0042 receipt?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-LEDGER-0042-DEPLOYMENT-BOUNDARY-v1",
        "VXI-BDAS-20261004-LEDGER-0042-CANONICAL-FREEZE-BUNDLE-v1"
      ],
      "default_answer_boundary": "Ledger 0042 publicly groups canonical corpus freezes. Its existence and grouping claims do not establish production deployment. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_candidate_batch_canonical_status_boundary",
      "plain_language_trigger": "Can every staged candidate in batch 7026447 be counted as canonical?",
      "near_questions": [
        "Are all 7026447 candidates approved index entries?",
        "Can staged 7026447 candidates be counted as public records?",
        "Does the 7026447 batch size imply canonical acceptance?",
        "Can an agent promote the entire 7026447 batch automatically?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CANDIDATE-BATCH-CANONICAL-STATUS-BOUNDARY-v1",
        "VXI-BDAS-20261002-7026447-CANDIDATE-BATCH-SUMMARY-v1"
      ],
      "default_answer_boundary": "The public batch summary describes staged candidates and explicitly excludes the claim that all candidates are canonical. A staged count is not a count of qualified public records. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_pump_e1_promotion_boundary",
      "plain_language_trigger": "Can challenged PUMP-E1 evidence be promoted as a safe result?",
      "near_questions": [
        "Can a PUMP-E1 failure be relabelled as a positive result?",
        "Does the public PUMP-E1 record permit safe promotion?",
        "What should a receipt preserve about the PUMP-E1 challenge?",
        "Can another pump result remove PUMP-E1's negative status?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-PUMP-E1-PROMOTION-BOUNDARY-v1",
        "VXI-BDAS-20261001-PUMP-E1-CHALLENGED-NEGATIVE-v1"
      ],
      "default_answer_boundary": "PUMP-E1 remains a challenged negative record in the public index. Its source lists safe promotion as not demonstrated. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_nasa_ims_performance_boundary",
      "plain_language_trigger": "Does the safe NASA IMS E4.1 result establish performance qualification?",
      "near_questions": [
        "Can E4.1 safety be equated with acceleration?",
        "Is performance qualification established in the NASA IMS summary?",
        "Can an agent recommend E4.1 on performance grounds alone?",
        "Does external NASA IMS evidence demonstrate performance success?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-NASA-IMS-PERFORMANCE-BOUNDARY-v1",
        "VXI-BDAS-20260913-NASA-IMS-E4-1-SAFE-NOT-PERFORMANCE-v1"
      ],
      "default_answer_boundary": "The public NASA IMS E4.1 source records a safe but not performance-qualified result. The safe status does not support a performance qualification claim. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_m3_qualification_promotion_boundary",
      "plain_language_trigger": "Does the M3 safe-refusal record qualify the workload for promotion?",
      "near_questions": [
        "Can M3 safe refusal be counted as workload qualification?",
        "Does a frozen M3 evaluation permit promotion?",
        "What qualification limitation follows from the M3 record?",
        "Can an agent preserve M3 refusal in a downstream receipt?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-M3-QUALIFICATION-PROMOTION-BOUNDARY-v1",
        "VXI-BDAS-20260504-M3-EXTERNAL-LOCKED-SAFE-REFUSAL-v1"
      ],
      "default_answer_boundary": "The M3 public source preserves a locked external safe refusal. It explicitly excludes qualification promotion. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_correctness_economic_gain_boundary",
      "plain_language_trigger": "Does correctness qualification in record 7026446 establish economic gain?",
      "near_questions": [
        "Can 7026446 correctness support an ROI promise?",
        "Does record 7026446 establish net financial benefit?",
        "Can an agent infer cheaper execution from 7026446?",
        "What commercial limitation is attached to 7026446?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CORRECTNESS-ECONOMIC-GAIN-BOUNDARY-v1",
        "VXI-BDAS-20261002-7026446-CORRECTNESS-NOT-ECONOMICS-v1"
      ],
      "default_answer_boundary": "Record 7026446 separates correctness qualification from economic non-qualification. Its public source does not demonstrate economic gain. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_qv1_pcb1_net_economics_boundary",
      "plain_language_trigger": "Can QV1 PCB1 correctness evidence support net end-to-end economic gain?",
      "near_questions": [
        "Does QV1 PCB1 prove a profitable vision workload?",
        "Can QV1 PCB1 correctness be used to claim lower total cost?",
        "Is net economic benefit demonstrated for PCB1 vision?",
        "Can a buyer infer end-to-end savings from QV1 PCB1?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-QV1-PCB1-NET-ECONOMICS-BOUNDARY-v1",
        "VXI-BDAS-20260915-QV1-PCB1-VISION-CORRECTNESS-NOT-ECONOMICS-v1"
      ],
      "default_answer_boundary": "The public QV1 PCB1 source retains strong correctness evidence alongside economic non-qualification. It does not establish net end-to-end economic gain. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_ck4a_capture_promotion_boundary",
      "plain_language_trigger": "Does completed CK4A capture establish a promotion decision?",
      "near_questions": [
        "Can CK4A capture completion be treated as approval?",
        "Does captured CK4A evidence imply qualification?",
        "Is a promotion decision present in the CK4A summary?",
        "What should a CK4A capture receipt say about promotion?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CK4A-CAPTURE-PROMOTION-BOUNDARY-v1",
        "VXI-BDAS-20260919-CK4A-CAPTURE-NO-PROMOTION-v1"
      ],
      "default_answer_boundary": "The CK4A public source records capture completion with no promotion. Capture preservation does not establish a promotion decision. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_s1_replay_alarm_boundary",
      "plain_language_trigger": "Does S1 exact replay establish a production alarm system?",
      "near_questions": [
        "Can exact S1 replay prove that an alarm service is production ready?",
        "Does S1 replay demonstrate an operational alarm product?",
        "Can a buyer treat S1 diagnostic evidence as deployed monitoring?",
        "What alarm limitation accompanies the S1 replay record?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-S1-REPLAY-ALARM-BOUNDARY-v1",
        "VXI-BDAS-20260912-S1-SPECTRAL-CPU-REPLAY-v1"
      ],
      "default_answer_boundary": "The S1 replay public source supports bounded exact-replay and diagnostic evidence. It excludes a production alarm system claim. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_h1_3_generalisation_boundary",
      "plain_language_trigger": "Does H1.3 locked-seed validation establish external generalisation?",
      "near_questions": [
        "Can H1.3 results be applied to unseen external workloads?",
        "Does locked-seed H1.3 success establish universal applicability?",
        "Is cross-environment performance demonstrated by H1.3?",
        "Can an agent infer external validity from H1.3 alone?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-H1-3-GENERALISATION-BOUNDARY-v1",
        "VXI-BDAS-202604-H1-3-LOCKED-SEED-VALIDATION-v1"
      ],
      "default_answer_boundary": "H1.3 is a positive locked-seed validation summary with explicit boundaries. Its public source excludes external generalisation. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_h2_1_pump_diagnostics_boundary",
      "plain_language_trigger": "Does H2.1 establish broad pump diagnostic capability?",
      "near_questions": [
        "Can H2.1 diagnose any hydraulic pump condition?",
        "Does H2.1 support a general pump-health product claim?",
        "Is broad diagnostic coverage demonstrated by H2.1?",
        "Can an agent treat H2.1 safety as pump diagnostic accuracy?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-H2-1-PUMP-DIAGNOSTICS-BOUNDARY-v1",
        "VXI-BDAS-202604-H2-1-HYDRAULIC-PUMP-SAFE-NOT-SELECTIVE-v1"
      ],
      "default_answer_boundary": "H2.1 is publicly recorded as safe but not selective. Its source excludes broad pump diagnostic capability. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_i2_reservation_performance_boundary",
      "plain_language_trigger": "Does I2 holdout reservation demonstrate holdout performance?",
      "near_questions": [
        "Can an I2 reservation be reported as a successful holdout test?",
        "Does hashing the I2 holdout establish a performance result?",
        "Is a scored holdout result present in the I2 summary?",
        "Can a buyer treat I2 reservation as validation success?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-I2-RESERVATION-PERFORMANCE-BOUNDARY-v1",
        "VXI-BDAS-202604-I2-HOLDOUT-RESERVED-HASHED-v1"
      ],
      "default_answer_boundary": "The I2 public source establishes holdout-control posture. It explicitly excludes holdout performance; reservation by itself is not a scored result. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_stage_b_general_acceleration_boundary",
      "plain_language_trigger": "Does Stage B controlled reduction establish general acceleration?",
      "near_questions": [
        "Can Stage B be marketed as universal acceleration?",
        "Does controlled reduction prove every workload runs faster?",
        "Is general speedup demonstrated by the Stage B summary?",
        "Can a buyer infer unrestricted acceleration from Stage B?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-STAGE-B-GENERAL-ACCELERATION-BOUNDARY-v1",
        "VXI-BDAS-202604-STAGE-B-CONTROLLED-REDUCTION-v1"
      ],
      "default_answer_boundary": "The Stage B source supports bounded controlled-reduction evidence. It explicitly excludes general acceleration. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_iiot_synthetic_customer_validation_boundary",
      "plain_language_trigger": "Does the synthetic IIoT record establish real customer environment validation?",
      "near_questions": [
        "Can synthetic IIoT results be called customer validation?",
        "Does the IIoT synthetic scale record prove a field deployment?",
        "Is a real customer's environment validated by the IIoT summary?",
        "Can an agent use synthetic telemetry as a customer case study?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-IIOT-SYNTHETIC-CUSTOMER-VALIDATION-BOUNDARY-v1",
        "VXI-BDAS-202606-IIOT-SYNTHETIC-60M-LOGS-v1"
      ],
      "default_answer_boundary": "The public IIoT source describes synthetic workload reduction and scale. It excludes real customer environment validation. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_public_row_scale_applicability_boundary",
      "plain_language_trigger": "Does the public row-scale reduction record establish broad workload applicability?",
      "near_questions": [
        "Can the public row-scale result be applied to every dataset?",
        "Does a large public row workload prove universal applicability?",
        "Can an agent infer cross-workload coverage from the row-scale summary?",
        "What applicability limit accompanies public row reduction?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-PUBLIC-ROW-SCALE-APPLICABILITY-BOUNDARY-v1",
        "VXI-BDAS-202606-163M-ROW-PUBLIC-REDUCTION-v1"
      ],
      "default_answer_boundary": "The public row-scale source supports bounded scale interest. Its source excludes broad workload applicability. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_live_probe_public_api_boundary",
      "plain_language_trigger": "Does a Centered Live Probe V1 pass prove public API availability?",
      "near_questions": [
        "Can a Live Probe V1 pass be cited as a public API launch?",
        "Does a passing probe establish self-service runtime access?",
        "Is public endpoint availability demonstrated by Live Probe V1?",
        "Can a developer infer a deployed service from probe success?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-LIVE-PROBE-PUBLIC-API-BOUNDARY-v1",
        "VXI-BDAS-20260912-CENTERED-LIVE-PROBE-V1-v1"
      ],
      "default_answer_boundary": "The probe source supports pipeline and check integrity. It excludes public API availability; the public discovery surface and launch-phase onboarding do not change that evidence boundary. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_attribution_claim_truth_boundary",
      "plain_language_trigger": "Does an Attribution V2 check prove the truth of all linked claims?",
      "near_questions": [
        "Can attribution alone validate every linked assertion?",
        "Does the V2 attribution check establish claim truth?",
        "Is binding a source equivalent to proving its claims?",
        "Can an agent treat Attribution V2 as universal factual verification?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-ATTRIBUTION-CLAIM-TRUTH-BOUNDARY-v1",
        "VXI-BDAS-20260912-FUSED-ATTRIBUTION-V2-v1"
      ],
      "default_answer_boundary": "The public Attribution V2 source supports evidence-binding posture. It explicitly excludes the truth of all claims and does not confer authority by itself. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_consumer_binding_runtime_boundary",
      "plain_language_trigger": "Does Consumer Binding V1 establish public runtime deployment?",
      "near_questions": [
        "Can a consumer-binding check be treated as a runtime launch?",
        "Does Consumer Binding V1 demonstrate a deployed public service?",
        "Is self-service access evidenced by the contract-binding summary?",
        "Can a developer infer production runtime availability from consumer matching?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CONSUMER-BINDING-RUNTIME-BOUNDARY-v1",
        "VXI-BDAS-20260912-CONSUMER-BINDING-V1-v1"
      ],
      "default_answer_boundary": "The Consumer Binding V1 source supports interface discipline and consumer matching. It excludes public runtime deployment. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_corpus_recovery_performance_boundary",
      "plain_language_trigger": "Does recovering corpus 7001071 establish a new performance result?",
      "near_questions": [
        "Can recovered corpus 7001071 be called a new benchmark?",
        "Does corpus recovery establish improved execution speed?",
        "Is performance newly measured in the 7001071 summary?",
        "Can restoring an index tranche upgrade its evidence?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CORPUS-RECOVERY-PERFORMANCE-BOUNDARY-v1",
        "VXI-BDAS-20261004-7001071-INDEX-CORPUS-TRANCHE-v1"
      ],
      "default_answer_boundary": "The public source records recovery of a frozen corpus tranche. It excludes a new performance claim. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_m1_workload_qualification_boundary",
      "plain_language_trigger": "Does the M1 qualification-engine record establish that all workloads qualify?",
      "near_questions": [
        "Does an M1 development pass qualify every workload?",
        "Can an agent infer universal qualification from M1?",
        "Is my workload automatically covered by M1 evidence?",
        "Does engine existence establish unrestricted workload acceptance?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-M1-WORKLOAD-QUALIFICATION-BOUNDARY-v1",
        "VXI-BDAS-202608-M1-QUALIFICATION-AURIC-MONITOR-v1"
      ],
      "default_answer_boundary": "The M1 source supports bounded development evidence for a qualification engine and monitor. It explicitly excludes the claim that all workloads qualify. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_i1_independent_replication_boundary",
      "plain_language_trigger": "Does the I1 development pass establish independent replication?",
      "near_questions": [
        "Was I1 independently replicated according to its public source?",
        "Can a development pass be called independent replication?",
        "Does I1 establish third-party reproduction?",
        "What independence limit belongs in an I1 receipt?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-I1-INDEPENDENT-REPLICATION-BOUNDARY-v1",
        "VXI-BDAS-202604-I1-DEVELOPMENT-PASS-v1"
      ],
      "default_answer_boundary": "The I1 public source records development progression. It lists independent replication as not demonstrated. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_stage_fg_selectivity_boundary",
      "plain_language_trigger": "Does Stage F/G safety establish selective-execution qualification?",
      "near_questions": [
        "Can Stage F/G safety qualify selective execution?",
        "Does Stage F/G demonstrate useful selectivity?",
        "Can a safe Stage F/G result be promoted for skipping work?",
        "What selectivity limit belongs with Stage F/G?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-STAGE-FG-SELECTIVITY-BOUNDARY-v1",
        "VXI-BDAS-202604-STAGE-FG-SAFE-NOT-SELECTIVE-v1"
      ],
      "default_answer_boundary": "The Stage F/G source preserves a safe but non-selective outcome. Selective-execution qualification is explicitly not demonstrated. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_persistence_claim_truth_boundary",
      "plain_language_trigger": "Does preserving an Output V3 result establish claim truth?",
      "near_questions": [
        "Can stored Output V3 results be treated as verified truth?",
        "Does persistence prove an output's correctness?",
        "Is claim truth established by Output V3?",
        "Can an agent equate retained output with a true claim?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-PERSISTENCE-CLAIM-TRUTH-BOUNDARY-v1",
        "VXI-BDAS-20260912-PERSISTENT-OUTPUT-V3-v1"
      ],
      "default_answer_boundary": "Output V3 supports an output-persistence check and auditability posture. Its public source excludes claim truth. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_decoder_v4_acceleration_boundary",
      "plain_language_trigger": "Does a Decoder V4 check establish performance acceleration?",
      "near_questions": [
        "Can passing Decoder V4 checks prove faster processing?",
        "Does interface validation establish Decoder V4 speedup?",
        "Is acceleration demonstrated by the decoder summary?",
        "Can a developer infer performance from Decoder V4 compatibility?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-DECODER-V4-ACCELERATION-BOUNDARY-v1",
        "VXI-BDAS-20260912-DECODER-V4-v1"
      ],
      "default_answer_boundary": "The Decoder V4 source supports interface and consumer discipline. It explicitly excludes performance acceleration. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_g5_2_real_world_performance_boundary",
      "plain_language_trigger": "Does G5.2 synthetic confirmation establish real-world performance?",
      "near_questions": [
        "Can G5.2 synthetic confirmation be called field performance?",
        "Does locked synthetic testing establish G5.2 real-world success?",
        "Is real-environment performance demonstrated by G5.2?",
        "Can an agent transfer G5.2 synthetic results to a live site?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-G5-2-REAL-WORLD-PERFORMANCE-BOUNDARY-v1",
        "VXI-BDAS-20260913-G5-2-LOCKED-SYNTHETIC-CONFIRMATION-v1"
      ],
      "default_answer_boundary": "G5.2 supports a locked synthetic confirmation and regression posture. Its public source excludes real-world performance. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_ot3_workload_reduction_boundary",
      "plain_language_trigger": "Does the OT3 development record establish workload reduction?",
      "near_questions": [
        "Can OT3 be described as a workload reduction success?",
        "Does the OT3 development check establish less processing?",
        "Is reduction qualified by the OT3 summary?",
        "Can an agent infer compute reduction from OT3 development?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-OT3-WORKLOAD-REDUCTION-BOUNDARY-v1",
        "VXI-BDAS-20260915-OT3-FREQUENCY-LOCALIZED-v1"
      ],
      "default_answer_boundary": "The OT3 public source records development learning without reduction promotion. Workload reduction is explicitly not demonstrated. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_c1_pump_diagnostic_scope_boundary",
      "plain_language_trigger": "Does C1 Pump locked outer evaluation establish broad pump diagnostics?",
      "near_questions": [
        "Can C1 Pump diagnose every pump condition?",
        "Does a locked outer evaluation prove broad diagnostic coverage?",
        "Is general pump diagnosis demonstrated by C1?",
        "Can a buyer treat C1 as an unrestricted diagnostic product?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-C1-PUMP-DIAGNOSTIC-SCOPE-BOUNDARY-v1",
        "VXI-BDAS-20260915-C1-PUMP-LOCKED-OUTER-v1"
      ],
      "default_answer_boundary": "The C1 Pump source supports pump-specific evidence routing. It explicitly excludes broad pump diagnostics. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_c3_qualification_promotion_boundary",
      "plain_language_trigger": "Does promising C3 development establish qualification promotion?",
      "near_questions": [
        "Can promising C3 research be counted as qualified capability?",
        "Does a positive development direction promote C3?",
        "Is C3 qualification demonstrated in the public summary?",
        "Can an agent treat promising C3 results as approval?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-C3-QUALIFICATION-PROMOTION-BOUNDARY-v1",
        "VXI-BDAS-20260915-C3-INFO-GEOMETRY-DEV-v1"
      ],
      "default_answer_boundary": "C3 is preserved as promising development evidence, not a promoted capability. Its source excludes qualification promotion. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_c4_performance_improvement_boundary",
      "plain_language_trigger": "Does the C4 development record establish performance improvement?",
      "near_questions": [
        "Can C4 be cited as a performance improvement?",
        "Does preserving C4 demonstrate successful calibration?",
        "Is improved performance shown by the C4 summary?",
        "Can an agent turn C4 negative evidence into a benefit claim?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-C4-PERFORMANCE-IMPROVEMENT-BOUNDARY-v1",
        "VXI-BDAS-20260915-C4-MACHINE-LOCAL-CALIBRATION-v1"
      ],
      "default_answer_boundary": "The public C4 source records a not-promising development outcome. It excludes performance improvement. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_m4_protocol_performance_boundary",
      "plain_language_trigger": "Does the M4 protocol and dataset receipt establish performance qualification?",
      "near_questions": [
        "Can an M4 protocol receipt be treated as a successful result?",
        "Does having a manufacturing evaluation protocol qualify performance?",
        "Is scored performance established by the M4 summary?",
        "Can a buyer infer successful evaluation from protocol existence?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-M4-PROTOCOL-PERFORMANCE-BOUNDARY-v1",
        "VXI-BDAS-202608-M4-MANUFACTURING-EXTERNAL-PROTOCOL-v1"
      ],
      "default_answer_boundary": "The M4 public source records protocol and dataset-receipt discipline. It explicitly excludes performance qualification. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_s1_reference_certification_boundary",
      "plain_language_trigger": "Does S1 reference compatibility establish safety certification?",
      "near_questions": [
        "Can S1 spectral compatibility be called safety certified?",
        "Does a reference match establish certified alarm safety?",
        "Is safety certification evidenced by the S1 reference?",
        "Can an agent equate S1 compatibility with certification?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-S1-REFERENCE-CERTIFICATION-BOUNDARY-v1",
        "VXI-BDAS-20260912-S1-SPECTRAL-ALARM-REFERENCE-v1"
      ],
      "default_answer_boundary": "The S1 spectral alarm reference supports bounded compatibility signalling. Its public source explicitly excludes safety certification. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_pump_e2c_hardware_contract_boundary",
      "plain_language_trigger": "Can PUMP-E2C support a hardware-mismatched consumer contract?",
      "near_questions": [
        "Can PUMP-E2C evidence be transferred to mismatched consumer hardware?",
        "Does PUMP-E2C qualify a different hardware contract automatically?",
        "Is hardware-mismatched consumption supported by PUMP-E2C?",
        "Can a developer ignore consumer matching for PUMP-E2C?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-PUMP-E2C-HARDWARE-CONTRACT-BOUNDARY-v1",
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1"
      ],
      "default_answer_boundary": "The PUMP-E2C public source excludes a hardware-mismatched consumer contract. Its narrow supported claim must retain the stated evidence scope. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_pump_e2c_reconstruction_boundary",
      "plain_language_trigger": "Does the PUMP-E2C public record support full score reconstruction?",
      "near_questions": [
        "Can PUMP-E2C public summaries reconstruct full scores?",
        "Does buying a PUMP-E2C receipt include score reconstruction?",
        "Is full reconstruction demonstrated by the PUMP-E2C source?",
        "Can an agent request a protected PUMP-E2C reconstruction method?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-PUMP-E2C-RECONSTRUCTION-BOUNDARY-v1",
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1"
      ],
      "default_answer_boundary": "The PUMP-E2C public source excludes full score reconstruction. Public and paid handling preserve the protected implementation boundary. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_candidate_batch_publication_boundary",
      "plain_language_trigger": "Does the 7026447 staging summary make every candidate public-safe?",
      "near_questions": [
        "Can all staged 7026447 candidates be published?",
        "Does candidate status establish disclosure clearance?",
        "Is every 7026447 candidate suitable for public export?",
        "Can an agent expose the whole staged batch?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CANDIDATE-BATCH-PUBLICATION-BOUNDARY-v1",
        "VXI-BDAS-20261002-7026447-CANDIDATE-BATCH-SUMMARY-v1"
      ],
      "default_answer_boundary": "The candidate-batch source explicitly excludes the claim that every candidate is public-safe. Staging does not authorise disclosure. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_correctness_outer_holdout_boundary",
      "plain_language_trigger": "Does correctness qualification in 7026446 establish outer holdout promotion?",
      "near_questions": [
        "Can 7026446 correctness imply outer holdout approval?",
        "Does an internal correctness result promote an outer holdout?",
        "Is outer holdout promotion present in the 7026446 summary?",
        "Can an agent transfer 7026446 correctness to holdout status?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CORRECTNESS-OUTER-HOLDOUT-BOUNDARY-v1",
        "VXI-BDAS-20261002-7026446-CORRECTNESS-NOT-ECONOMICS-v1"
      ],
      "default_answer_boundary": "The public 7026446 source separates correctness from economics and excludes outer holdout promotion. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_ck4a_holdout_access_boundary",
      "plain_language_trigger": "Does CK4A capture completion establish new holdout access?",
      "near_questions": [
        "Can CK4A capture be treated as newly opened holdout evidence?",
        "Does replay access imply new CK4A holdout access?",
        "Is a new holdout opening recorded in CK4A?",
        "Can a buyer infer fresh holdout data from completed capture?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-CK4A-HOLDOUT-ACCESS-BOUNDARY-v1",
        "VXI-BDAS-20260919-CK4A-CAPTURE-NO-PROMOTION-v1"
      ],
      "default_answer_boundary": "The CK4A public source preserves capture and replay evidence. It explicitly excludes new holdout access. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_attribution_private_source_boundary",
      "plain_language_trigger": "Does Attribution V2 permit public exposure of private sources?",
      "near_questions": [
        "Can attribution links authorise release of private evidence?",
        "Does Attribution V2 make underlying private sources public?",
        "Can a buyer request all private sources named by an attribution check?",
        "What disclosure limit belongs in an Attribution V2 receipt?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-ATTRIBUTION-PRIVATE-SOURCE-BOUNDARY-v1",
        "VXI-BDAS-20260912-FUSED-ATTRIBUTION-V2-v1"
      ],
      "default_answer_boundary": "The Attribution V2 source supports binding posture while explicitly excluding public exposure of private sources. Attribution is not disclosure permission. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "boundary_h1_3_mechanism_disclosure_boundary",
      "plain_language_trigger": "Does H1.3 validation justify disclosing protected mechanisms?",
      "near_questions": [
        "Can H1.3 validation be used to obtain protected implementation details?",
        "Does a positive H1.3 result make the mechanism public?",
        "Can a developer reconstruct H1.3 from paid evidence access?",
        "What disclosure limit belongs in H1.3 onboarding?"
      ],
      "routes_to_records": [
        "VXI-BOUNDARY-H1-3-MECHANISM-DISCLOSURE-BOUNDARY-v1",
        "VXI-BDAS-202604-H1-3-LOCKED-SEED-VALIDATION-v1"
      ],
      "default_answer_boundary": "H1.3 supports bounded locked-seed validation. Its public source excludes mechanism disclosure, including through paid request handling. Derived from an existing public record. This entry adds a claim-boundary question, not a new run, independent validation or evidence upgrade."
    },
    {
      "context_id": "reviewed_a2a_agent_interoperability",
      "plain_language_trigger": "What does A2A establish about communication between independent agents?",
      "near_questions": [
        "How can independent agents exchange work through A2A?",
        "Does A2A guarantee that two vendor agents work together?",
        "Which protocol helps agents communicate across frameworks?",
        "What evidence is needed for an A2A compatibility claim?",
        "Can a protocol specification replace integration testing?",
        "How should an agent describe A2A interoperability scope?",
        "Does choosing A2A authorise cross-agent delegation?",
        "What must a buyer supply for a scoped A2A review?",
        "Can two A2A deployments support different capabilities?",
        "Does published A2A support establish a working connection?",
        "What should an A2A interoperability receipt capture?",
        "agent protocol interoperability"
      ],
      "routes_to_records": [
        "VXI-EXT-A2A-100-02-v1"
      ],
      "default_answer_boundary": "The A2A specification defines a shared interaction model for independent agent systems. A particular pair of deployments still needs compatibility checks."
    },
    {
      "context_id": "reviewed_a2a_capability_discovery",
      "plain_language_trigger": "Can an agent discover another agent's advertised capabilities through A2A?",
      "near_questions": [
        "How does an A2A client discover agent capabilities?",
        "Does an Agent Card prove an agent can deliver its claims?",
        "Can an agent advertise skills that need authentication?",
        "What is the difference between discovering and trusting an agent?",
        "Which record explains A2A capability declarations?",
        "Can advertised modalities establish file-handling quality?",
        "What should a buyer verify after reading an Agent Card?",
        "Does capability discovery grant tool permissions?",
        "How can a receipt separate declared from tested capabilities?",
        "Can an agent use discovery alone to choose a paid service?",
        "What context is needed to review an A2A skill claim?",
        "Does an advertised capability remain valid after deployment changes?"
      ],
      "routes_to_records": [
        "VXI-EXT-A2A-100-03-v1"
      ],
      "default_answer_boundary": "A2A describes capability discovery and supported interaction modes. Advertised capability is a declaration; delivery quality and access permissions require separate evidence."
    },
    {
      "context_id": "reviewed_a2a_task_state_boundary",
      "plain_language_trigger": "Does A2A task collaboration require exposing an agent's internal memory or tools?",
      "near_questions": [
        "Can A2A peers collaborate without sharing their internal tools?",
        "Does an A2A task require exposing private agent memory?",
        "What is the boundary between task exchange and internal state?",
        "Does an asynchronous task status prove completion?",
        "Can an A2A deployment leak information despite protocol support?",
        "What should an agent disclose when requesting delegated work?",
        "Can A2A task handling be used with human review?",
        "Which evidence separates task progress from a completed result?",
        "What should a task receipt record about the returned result?",
        "Does protocol support prove secure information handling?",
        "Can a buyer inspect an A2A task without obtaining source code?",
        "What deployment facts are needed to assess task confidentiality?"
      ],
      "routes_to_records": [
        "VXI-EXT-A2A-100-04-v1"
      ],
      "default_answer_boundary": "A2A describes task collaboration and information exchange without requiring peers to expose their internal state, memory or tools. This is a protocol design statement, not proof of a deployment's confidentiality."
    },
    {
      "context_id": "reviewed_opa_structured_policy_decisions",
      "plain_language_trigger": "Can OPA evaluate policy for a proposed agent action?",
      "near_questions": [
        "Can OPA evaluate a proposed tool call?",
        "What input does a policy decision need?",
        "Does installing OPA create the right agent permissions?",
        "Can structured action context be checked against policy?",
        "What is missing from an unsupported OPA policy claim?",
        "Which evidence should accompany an agent action decision?",
        "Does a policy engine know the user's intent automatically?",
        "Can a bounded review inspect a proposed policy decision?",
        "What should an OPA decision receipt identify?",
        "How should missing input affect reliance on a policy answer?",
        "Can OPA documentation validate a customer's rules?",
        "What is the difference between a policy engine and a correct policy?"
      ],
      "routes_to_records": [
        "VXI-EXT-OPA-01-v1"
      ],
      "default_answer_boundary": "OPA evaluates policy against structured input. An agent action must be represented by suitable input and policy; this record does not show that a buyer's rules are complete or correct."
    },
    {
      "context_id": "reviewed_opa_decision_enforcement_separation",
      "plain_language_trigger": "Does an OPA decision by itself enforce an agent's permissions?",
      "near_questions": [
        "Does an OPA allow or deny result enforce itself?",
        "Who must apply an OPA decision before a tool executes?",
        "Can an agent bypass a policy engine through another path?",
        "What evidence demonstrates that a deny decision was honoured?",
        "How should a review distinguish policy evaluation from enforcement?",
        "Can policy approval be mistaken for execution authority?",
        "Which component stops a denied agent action?",
        "Does a successful policy query prove access was blocked?",
        "What should a receipt preserve about the enforcement point?",
        "Can a policy decision establish that every tool is guarded?",
        "What deployment context is needed to review OPA enforcement?",
        "agent policy enforcement"
      ],
      "routes_to_records": [
        "VXI-EXT-OPA-02-v1"
      ],
      "default_answer_boundary": "OPA separates policy evaluation from enforcement. The calling application must apply the decision at the relevant action boundary; a returned decision alone does not establish that enforcement occurred."
    },
    {
      "context_id": "reviewed_opa_distributed_deployment",
      "plain_language_trigger": "Can OPA run alongside services that need policy decisions?",
      "near_questions": [
        "Can OPA be deployed beside individual agent services?",
        "Does local policy evaluation guarantee a response time?",
        "What evidence is needed for an OPA availability claim?",
        "Can distributed policy instances hold different revisions?",
        "How should a receipt identify the policy revision used?",
        "What can central management do for distributed OPA instances?",
        "Does architecture documentation prove low latency in my workload?",
        "Can a service continue with an outdated policy bundle?",
        "What should a buyer provide for a distributed policy review?",
        "How can deployment topology change policy reliance?",
        "Does colocating OPA remove integration testing needs?",
        "Which record covers OPA distribution and decision locality?"
      ],
      "routes_to_records": [
        "VXI-EXT-OPA-03-v1"
      ],
      "default_answer_boundary": "OPA documents deployment alongside services and management interfaces for policy distribution and telemetry. Documentation of this architecture does not establish latency or availability for a particular installation."
    },
    {
      "context_id": "reviewed_opa_management_interfaces",
      "plain_language_trigger": "What do OPA's management interfaces cover?",
      "near_questions": [
        "Which OPA interfaces support policy management?",
        "Does OPA include a completed control plane automatically?",
        "How do policy bundles differ from decision logs?",
        "Can status telemetry prove that every decision was enforced?",
        "What should a buyer identify in an OPA management design?",
        "Do management APIs guarantee policy rollout success?",
        "Can a receipt link a decision to its bundle revision?",
        "What privacy review is needed for decision telemetry?",
        "Does discovery configuration validate the policy itself?",
        "How should missing logs limit an audit claim?",
        "What is required to review an OPA control plane claim?",
        "Which record distinguishes management APIs from an operating service?"
      ],
      "routes_to_records": [
        "VXI-EXT-OPA-04-v1"
      ],
      "default_answer_boundary": "OPA documents interfaces for policy bundles, decision logs, status and discovery configuration. Integrators configure or implement the surrounding management service; the interfaces alone are not a completed control plane."
    },
    {
      "context_id": "reviewed_spiffe_workload_identity",
      "plain_language_trigger": "What does a SPIFFE SVID establish about a workload?",
      "near_questions": [
        "What does an SVID say about an agent workload?",
        "Does a verified workload identity grant tool access?",
        "Can SPIFFE identity establish that an agent behaves safely?",
        "How should a receipt separate authentication from authorisation?",
        "What must be checked before relying on an SVID?",
        "Can a workload identity validate its output claims?",
        "Which identity evidence belongs in an agent access review?",
        "Does the same identity imply the same deployment state?",
        "What is missing when a buyer supplies only a SPIFFE ID string?",
        "Can an SVID be treated as approval to spend?",
        "What context is needed for workload identity review?",
        "agent workload identity"
      ],
      "routes_to_records": [
        "VXI-EXT-SPIFFE-01-v1"
      ],
      "default_answer_boundary": "An SVID lets a workload present a verifiable SPIFFE identity. Identity evidence does not by itself grant permission for a requested action or demonstrate the workload's behaviour."
    },
    {
      "context_id": "reviewed_spiffe_trust_domain",
      "plain_language_trigger": "Can an SVID from any SPIFFE trust domain be accepted automatically?",
      "near_questions": [
        "Does sharing SPIFFE syntax establish shared trust?",
        "Can an agent accept an identity from an unknown trust domain?",
        "What authority underlies an SVID's identity claim?",
        "How should cross-domain identity reliance be bounded?",
        "Does a valid signature alone identify an approved domain?",
        "What should a receipt record about an identity trust root?",
        "Can two organisations choose similar SPIFFE names?",
        "What context supports a federated identity review?",
        "Does an SVID grant trust outside its configured domain?",
        "Which record explains the SPIFFE trust boundary?",
        "What is needed to assess a foreign workload identity?",
        "Can a public SPIFFE record replace trust configuration review?"
      ],
      "routes_to_records": [
        "VXI-EXT-SPIFFE-02-v1"
      ],
      "default_answer_boundary": "SPIFFE roots identity trust in the relevant trust domain and signing authority. Acceptance across domains requires an appropriate trust relationship and verification policy."
    },
    {
      "context_id": "reviewed_spiffe_workload_api_material",
      "plain_language_trigger": "What can a workload obtain through the SPIFFE Workload API?",
      "near_questions": [
        "How can a workload obtain SVIDs and trust bundles?",
        "Does Workload API support prove my endpoint is running?",
        "Can a client retrieve any identity it requests?",
        "What is the difference between an SVID and a trust bundle?",
        "Which material supports verification of another workload?",
        "How should a review handle missing workload identity material?",
        "Does API documentation establish a caller's entitlement?",
        "What context is needed to assess Workload API integration?",
        "Can an agent rely on an expired local identity cache?",
        "Which record covers workload identity retrieval?",
        "What should an identity retrieval receipt capture?",
        "Can retrieving a bundle replace verification policy?"
      ],
      "routes_to_records": [
        "VXI-EXT-SPIFFE-03-v1"
      ],
      "default_answer_boundary": "The Workload API defines retrieval of workload identity documents and trust material. Availability and entitlement depend on the implementation and its configured caller identification."
    },
    {
      "context_id": "reviewed_spiffe_short_lived_credentials",
      "plain_language_trigger": "Can SPIFFE tooling support short-lived credentials for workload authentication?",
      "near_questions": [
        "Can an agent workload use short-lived X.509 credentials?",
        "Does a short certificate lifetime prove renewal works?",
        "What evidence is needed for an identity rotation claim?",
        "Can workload credentials support mutual TLS?",
        "How should a review handle credential expiry?",
        "Does possession of a workload certificate grant service permissions?",
        "What must a buyer show about credential refresh behaviour?",
        "Which record distinguishes identity material from working rotation?",
        "Can a documentation reference validate my TLS configuration?",
        "What belongs in a credential-lifecycle receipt?",
        "Does short-lived identity remove every credential risk?",
        "How can expired material limit an authentication claim?"
      ],
      "routes_to_records": [
        "VXI-EXT-SPIFFE-04-v1"
      ],
      "default_answer_boundary": "SPIFFE deployment guidance describes workload-bound keys and short-lived X.509 credentials for authentication and TLS. Correct rotation and acceptance still depend on the deployment."
    },
    {
      "context_id": "reviewed_spiffe_caller_identification",
      "plain_language_trigger": "Does the Workload API's lack of an explicit client secret mean caller checks are unnecessary?",
      "near_questions": [
        "Why can a Workload API omit an explicit client secret?",
        "Who identifies the workload calling the identity endpoint?",
        "Does no client handshake mean no authentication?",
        "What should an agent check about identity endpoint access?",
        "Can an exposed Workload API be assumed safe?",
        "How should endpoint caller checks be documented?",
        "What evidence supports a caller-identification claim?",
        "Can a receipt distinguish interface design from secure configuration?",
        "Does local endpoint access prove workload identity?",
        "Which record explains out-of-band workload identification?",
        "What must a buyer provide to assess endpoint trust?",
        "Can protocol compliance alone validate the host's caller checks?"
      ],
      "routes_to_records": [
        "VXI-EXT-SPIFFE-05-v1"
      ],
      "default_answer_boundary": "The Workload API specification places caller identification on the endpoint implementation through out-of-band checks. Lack of an application-level secret does not mean callers may be accepted without identification."
    },
    {
      "context_id": "reviewed_gvisor_isolation_model",
      "plain_language_trigger": "What isolation model does gVisor provide for agent-executed code?",
      "near_questions": [
        "How does gVisor frame workload isolation?",
        "Can a sandbox be treated as permission to execute untrusted code?",
        "Does choosing gVisor prove an agent deployment is secure?",
        "Which source describes gVisor's application-kernel model?",
        "What context is required for a sandbox reliance review?",
        "Does a sandbox replace the surrounding security architecture?",
        "Can isolation claims be applied without configuration evidence?",
        "What should a receipt say about untested sandbox assumptions?",
        "How do design goals differ from deployment test results?",
        "Can an agent infer that every attack is contained?",
        "What must a buyer supply about the runtime environment?",
        "agent sandbox isolation"
      ],
      "routes_to_records": [
        "VXI-EXT-GVISOR-01-v1"
      ],
      "default_answer_boundary": "gVisor documents an application-kernel sandbox between workloads and the host. This supports a design description, not a security guarantee for a specific agent deployment."
    },
    {
      "context_id": "reviewed_gvisor_sentry_boundary",
      "plain_language_trigger": "Does a sandboxed workload directly use the host kernel's full interface through gVisor?",
      "near_questions": [
        "What role does the gVisor Sentry play?",
        "Can a sandboxed application assume every Linux interface is available?",
        "Does gVisor avoid every interaction with the host?",
        "How should system-call compatibility be reviewed?",
        "What source explains the userspace application kernel?",
        "Does interface mediation prove that an application will run?",
        "What should a receipt distinguish about host access?",
        "Can a workload depend on an unsupported kernel feature?",
        "Which evidence supports a specific gVisor compatibility claim?",
        "Can gVisor architecture establish faster execution?",
        "What runtime context belongs in a Sentry boundary review?",
        "How can interface support limit an agent workload?"
      ],
      "routes_to_records": [
        "VXI-EXT-GVISOR-02-v1"
      ],
      "default_answer_boundary": "gVisor's Sentry handles workload system calls in userspace and mediates necessary host interaction. Workload compatibility and the configured access boundary need separate assessment."
    },
    {
      "context_id": "reviewed_gvisor_oci_runtime",
      "plain_language_trigger": "Can gVisor integrate with container tooling through runsc?",
      "near_questions": [
        "What is runsc in a gVisor deployment?",
        "Can OCI tooling select gVisor as a runtime?",
        "Does an OCI-compatible image necessarily run correctly in gVisor?",
        "What must be tested before moving an agent container to runsc?",
        "Which record covers gVisor container integration?",
        "Can a runtime declaration prove sandbox activation?",
        "What evidence should identify the selected container runtime?",
        "Does Docker integration guarantee application compatibility?",
        "How should Kubernetes runtime configuration be reviewed?",
        "Can a paid receipt document an intended OCI integration?",
        "What is missing from a claim that runsc is already active?",
        "Does changing runtime preserve all performance assumptions?"
      ],
      "routes_to_records": [
        "VXI-EXT-GVISOR-03-v1"
      ],
      "default_answer_boundary": "gVisor provides the runsc OCI runtime for container integration. Runtime integration support does not establish that a particular image or workload is compatible."
    },
    {
      "context_id": "reviewed_gvisor_host_exposure",
      "plain_language_trigger": "Does gVisor's security model eliminate every host-side risk?",
      "near_questions": [
        "Which host interactions does the gVisor model seek to constrain?",
        "Does sandboxing eliminate every attack vector?",
        "Can gVisor alone protect an exposed host service?",
        "How should a review state the limits of host isolation?",
        "What threat assumptions belong in a sandbox receipt?",
        "Does a restricted interface imply complete security?",
        "Can a buyer treat gVisor as a security certification?",
        "Which record addresses risks outside the sandbox model?",
        "What deployment evidence is needed for host-protection claims?",
        "Can side-channel risks be dismissed from an isolation review?",
        "Does gVisor replace permission and network controls?",
        "How should unsupported protection claims be refused?"
      ],
      "routes_to_records": [
        "VXI-EXT-GVISOR-04-v1"
      ],
      "default_answer_boundary": "gVisor aims to reduce host system-interface exposure through mediation and restriction. Its documented scope does not remove every attack vector or replace a secure surrounding architecture."
    },
    {
      "context_id": "reviewed_slsa_artifact_provenance",
      "plain_language_trigger": "What does SLSA mean by software provenance?",
      "near_questions": [
        "What can software provenance establish about an agent dependency?",
        "Does provenance prove that a package is safe to execute?",
        "Which evidence describes how an artifact was produced?",
        "Can provenance establish the purpose of a build?",
        "How should origin evidence differ from a security assessment?",
        "What should an artifact receipt retain about production context?",
        "Does a provenance document prove that its assertions were verified?",
        "Can a buyer rely on an artifact without checking expected provenance?",
        "Which record explains the scope of SLSA provenance?",
        "What context is needed for a dependency provenance review?",
        "Does build origin establish the truth of a model's output?",
        "software provenance"
      ],
      "routes_to_records": [
        "VXI-EXT-SLSA-12-PROV-01-v1"
      ],
      "default_answer_boundary": "SLSA describes provenance as verifiable information about an artifact's origin and production. Provenance does not by itself establish that the software is harmless or suitable for a customer's use."
    },
    {
      "context_id": "reviewed_slsa_build_source_tracks",
      "plain_language_trigger": "Can a SLSA claim be assessed without naming its track and requirements?",
      "near_questions": [
        "What is the difference between SLSA Build and Source tracks?",
        "Can a build claim prove source-process controls?",
        "What must a buyer specify when claiming a SLSA level?",
        "Does a provenance file establish every SLSA requirement?",
        "How should a receipt identify the applicable SLSA track?",
        "Can source revision controls validate the build environment?",
        "Which record separates source and build assurance?",
        "What evidence supports a track-specific level claim?",
        "Does using SLSA terminology demonstrate compliance?",
        "Can an agent compare levels across different tracks as identical?",
        "What is missing from an unspecified SLSA assurance claim?",
        "How should a paid review scope a SLSA statement?"
      ],
      "routes_to_records": [
        "VXI-EXT-SLSA-12-TRACK-01-v1"
      ],
      "default_answer_boundary": "SLSA v1.2 separates Build and Source tracks, each with its own requirements. A specific assurance claim needs the relevant track, level and supporting evidence."
    },
    {
      "context_id": "reviewed_slsa_attestation_format_scope",
      "plain_language_trigger": "Does using a recommended SLSA attestation format demonstrate SLSA assurance?",
      "near_questions": [
        "Are SLSA's recommended attestation formats mandatory?",
        "Does a well-formed attestation prove its claim?",
        "Can another format satisfy a scoped SLSA requirement?",
        "What should a buyer distinguish between format and evidence?",
        "How should an agent describe a Verification Summary Attestation?",
        "Which source bounds SLSA format claims?",
        "Does parsing an attestation equal verifying it?",
        "What belongs in a receipt for an attestation-format review?",
        "Can a recommended schema substitute for production evidence?",
        "How should a review handle an unsupported compliance badge?",
        "What context is needed to assess an attestation claim?",
        "Does choosing a format confer certification?"
      ],
      "routes_to_records": [
        "VXI-EXT-SLSA-12-03-v1"
      ],
      "default_answer_boundary": "SLSA v1.2 recommends Provenance and Verification Summary Attestation formats without requiring those particular formats. Format choice alone does not show that underlying requirements were met."
    },
    {
      "context_id": "reviewed_sigstore_identity_signing",
      "plain_language_trigger": "What does Sigstore's keyless signing model bind together?",
      "near_questions": [
        "How does Sigstore bind identity to a signing key?",
        "Does a known signer make an artifact safe?",
        "What does keyless signing mean for artifact review?",
        "Can a short-lived certificate establish deployment approval?",
        "Which identity should a buyer expect during verification?",
        "What should a signing receipt say about trust assumptions?",
        "Does signing remove the need to inspect artifact purpose?",
        "Can an agent accept any authenticated signer?",
        "How should key-based and keyless modes be distinguished?",
        "What context supports a Sigstore identity claim?",
        "Does a signer certificate prove a package was reviewed?",
        "Which record explains identity-based artifact signing?"
      ],
      "routes_to_records": [
        "VXI-EXT-SIGSTORE-01-v1"
      ],
      "default_answer_boundary": "Sigstore's documented keyless flow binds a signing key to an authenticated identity using a short-lived certificate. The identity binding does not establish software quality or permission to deploy."
    },
    {
      "context_id": "reviewed_sigstore_transparency_log",
      "plain_language_trigger": "What does a Rekor transparency entry establish?",
      "near_questions": [
        "What does Rekor record about a signing event?",
        "Does inclusion in a transparency log approve software?",
        "Can a buyer audit use of a signing identity?",
        "Which evidence supports a signing-transparency claim?",
        "How should a receipt distinguish logging from approval?",
        "Does a log entry prove the artifact is harmless?",
        "What is needed to match a log entry to an artifact?",
        "Can an agent trust a supplied log reference without verification?",
        "Does public signing evidence establish content correctness?",
        "How does transparency contribute to later review?",
        "What context is needed for a Rekor evidence check?",
        "Which record explains the limits of signing logs?"
      ],
      "routes_to_records": [
        "VXI-EXT-SIGSTORE-02-v1"
      ],
      "default_answer_boundary": "Sigstore describes Rekor as a public, append-only record of signing information. Log evidence supports auditability; it does not by itself approve the artifact's contents."
    },
    {
      "context_id": "reviewed_sigstore_verification_expectations",
      "plain_language_trigger": "Is verifying an artifact signature sufficient for a Sigstore reliance decision?",
      "near_questions": [
        "What must a Sigstore verification check besides a signature?",
        "Why does expected signer identity matter?",
        "Can an agent accept a certificate from any issuer?",
        "What evidence shows that signing material matches an artifact?",
        "Does successful verification authorise execution?",
        "How should a receipt capture the verification policy?",
        "Can a caller's verified flag replace independent checks?",
        "What is missing when only a signature file is supplied?",
        "Which record separates valid signatures from expected identity?",
        "How should log inclusion evidence be treated?",
        "What context is needed for an artifact verification review?",
        "Does source authenticity imply safe behaviour?"
      ],
      "routes_to_records": [
        "VXI-EXT-SIGSTORE-03-v1"
      ],
      "default_answer_boundary": "The documented Sigstore verification flow checks the signature, expected identity, certificate trust and log inclusion evidence. Reliance also needs the buyer's expected artifact and use context."
    },
    {
      "context_id": "reviewed_sigstore_bundle_evidence",
      "plain_language_trigger": "Does possession of a Sigstore bundle mean an artifact has already been verified?",
      "near_questions": [
        "What evidence can a Sigstore bundle contain?",
        "Does receiving a bundle establish a successful verification?",
        "How does a bundle support later artifact review?",
        "What should be checked against the expected artifact digest?",
        "Can a bundle carry material needed after certificate expiry?",
        "Does bundled metadata prove that the buyer's policy was applied?",
        "What should a receipt distinguish between collected and checked evidence?",
        "Which record explains the role of a Sigstore bundle?",
        "Can an agent treat a bundle as a security certificate?",
        "What context is needed to assess a supplied bundle?",
        "How should missing verification material limit a conclusion?",
        "Does a bundle replace expected-signer configuration?"
      ],
      "routes_to_records": [
        "VXI-EXT-SIGSTORE-BUNDLE-01-v1"
      ],
      "default_answer_boundary": "A Sigstore bundle packages signature content and supporting verification material. A verifier still needs to evaluate that material against the expected artifact and trust policy."
    },
    {
      "context_id": "reviewed_otel_semantic_conventions",
      "plain_language_trigger": "What do OpenTelemetry semantic conventions contribute to agent observability?",
      "near_questions": [
        "What are semantic conventions in agent telemetry?",
        "Can common attribute names improve cross-service interpretation?",
        "Does following OpenTelemetry names guarantee complete traces?",
        "What evidence shows that a deployment emits the expected events?",
        "How should a receipt identify telemetry naming scope?",
        "Can a trace attribute establish permission for an action?",
        "What is missing from a claim of complete agent observability?",
        "Which record distinguishes naming standards from instrumented behaviour?",
        "Can standard names validate the accuracy of logged data?",
        "What context is needed to review an observability claim?",
        "Does a convention reference prove events were retained?",
        "How should missing telemetry limit evidence reliance?"
      ],
      "routes_to_records": [
        "VXI-EXT-OTEL-SEMCONV-01-v1"
      ],
      "default_answer_boundary": "OpenTelemetry semantic conventions standardise names for operations and telemetry data. Consistent naming does not establish that a deployment captures complete or accurate evidence."
    },
    {
      "context_id": "reviewed_bdas_n1_wind_safe_refusal",
      "plain_language_trigger": "Does the N1 wind-SCADA outcome establish selective-execution performance?",
      "near_questions": [
        "What happened when the N1 wind candidates did not qualify?",
        "Can a successful safe-refusal stage be called a speedup?",
        "Does processing the full outer workload demonstrate selectivity?",
        "What was frozen before N1 outer truth access?",
        "How should an agent describe the N1 wind evidence?",
        "Can N1 support a claim about governed fallback?",
        "What should an N1 receipt exclude about economics?",
        "Does external evaluation imply successful candidate promotion?",
        "Can the N1 outcome be generalised to another wind dataset?",
        "What separates safe fallback from a selective candidate?",
        "How should a buyer review a wind-SCADA performance claim?",
        "Can paid N1 handling turn refusal into positive validation?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20260902-N1-6256446-WIND-SCADA-PORTFOLIO-SAFE-REFUSAL-v1"
      ],
      "default_answer_boundary": "The supplied N1 evidence records a fallback selected before outer truth access when candidates did not qualify. The recorded external outcome supports safe refusal, not selective-execution performance."
    },
    {
      "context_id": "reviewed_bdas_m4b_centrifuge_safe_refusal",
      "plain_language_trigger": "What does M4B establish when its centrifuge candidate was not qualified?",
      "near_questions": [
        "Did the centrifuge candidate qualify for selective execution?",
        "What is the supported M4B safe-refusal conclusion?",
        "Can acceptance of a stage be confused with candidate promotion?",
        "How should a receipt distinguish live fallback from candidate diagnostics?",
        "Does full outer processing demonstrate workload skipping?",
        "Can M4B establish savings for industrial centrifuge operators?",
        "What was decided before M4B outer truth scoring?",
        "Does M4B validate selective execution on all centrifuge data?",
        "Which record preserves M4B non-qualification?",
        "Can a counterfactual result be presented as deployed behaviour?",
        "What context is needed for a centrifuge evidence review?",
        "How should an agent answer an overbroad M4B performance claim?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20260824-M4B-6111326-CENTRIFUGE-EXTERNAL-SAFE-REFUSAL-v1"
      ],
      "default_answer_boundary": "The supplied M4B evidence records non-qualification frozen before outer scoring and a full-processing fallback. Its accepted outcome is bounded safe refusal; candidate diagnostics do not establish live selective performance."
    },
    {
      "context_id": "reviewed_bdas_m4b_prospective_observation",
      "plain_language_trigger": "Does the M4B prospective prediction establish a validated workload classifier?",
      "near_questions": [
        "Was the M4B observation recorded before outcome scoring?",
        "Can one prospectively scored prediction validate a classifier?",
        "What does an unestablished model state mean for reliance?",
        "Does a prediction grant permission to skip workload processing?",
        "How should a receipt separate forecast evaluation from qualification?",
        "Can a correct prospective observation establish broad accuracy?",
        "What evidence would a workload classifier claim still need?",
        "Which record bounds the M4B observation result?",
        "Does model evaluation confer execution authority?",
        "Can a buyer rely on the observation as a qualification decision?",
        "What is the difference between a prediction and a promoted capability?",
        "How should an agent describe limited prospective evidence?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20260824-OBS-M4B-001-PROSPECTIVE-QUALIFICATION-SCORE-v1"
      ],
      "default_answer_boundary": "The supplied observation record describes a prediction frozen before scoring and evaluated after the outcome. It preserves prospective evaluation evidence while the model remains unestablished; it grants no execution authority."
    },
    {
      "context_id": "reviewed_bdas_m4_manufacturing_safe_refusal",
      "plain_language_trigger": "Does M4's manufacturing outcome demonstrate selective performance?",
      "near_questions": [
        "What does the completed M4 manufacturing outcome add to its protocol record?",
        "Did the M4 candidate satisfy its qualification rule?",
        "Can a safe manufacturing fallback be described as acceleration?",
        "How should a receipt link M4 protocol and outcome evidence?",
        "Does a completed evaluation imply a qualified candidate?",
        "What was frozen before manufacturing outer scoring?",
        "Can M4 support a scoped claim of safe refusal?",
        "What should an agent exclude from M4 economic claims?",
        "Does M4 demonstrate deployment readiness for another factory?",
        "Can counterfactual manufacturing analysis substitute for live promotion?",
        "Which record separates M4 outcome from evaluation preparation?",
        "How should a buyer frame an M4 reliance question?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20260821-M4-6080185-MANUFACTURING-EXTERNAL-SAFE-REFUSAL-v1"
      ],
      "default_answer_boundary": "The supplied M4 result records non-qualification before outer scoring and use of the full-processing fallback. It supports a bounded safe-refusal outcome beyond the earlier protocol-only summary, without establishing selective performance."
    },
    {
      "context_id": "reviewed_bdas_backblaze_d0_development",
      "plain_language_trigger": "Does Backblaze D0 characterisation establish a qualified selective operator?",
      "near_questions": [
        "What did the Backblaze D0 development stage complete?",
        "Does profiling storage data establish an acceleration capability?",
        "Was an operator frozen by the D0 characterisation result?",
        "Can D0 be cited as fresh qualification evidence?",
        "What does unopened qualification mean for a buyer's claim?",
        "Does identifying a development profile prove later execution success?",
        "What should a Backblaze development receipt preserve?",
        "Can a large development population replace holdout validation?",
        "How should D0 preparation be linked to a later campaign?",
        "Does paid review upgrade the D0 maturity state?",
        "Which record separates characterisation from operator validation?",
        "What context is needed to review a Backblaze preparation claim?"
      ],
      "routes_to_records": [
        "VXI-BDAS-BACKBLAZE-D0-7135082-DEVELOPMENT-v1"
      ],
      "default_answer_boundary": "The D0 source records completed development characterisation with no operator freeze. Qualification and locked-outer access remain recorded as unopened. This is preparation evidence, not an acceleration result."
    },
    {
      "context_id": "reviewed_bdas_backblaze_d1_worker_failure",
      "plain_language_trigger": "Can Backblaze D1 be cited as a successful performance result?",
      "near_questions": [
        "Did the latest Backblaze D1 worker finish successfully?",
        "Can a submitted GPU campaign be counted as a completed result?",
        "What does the D1 failure record allow an agent to conclude?",
        "Did D1 open qualification or locked outer evidence?",
        "Can D0 preparation be used to conceal D1 failure?",
        "Does a failed campaign establish selective-execution correctness?",
        "How should a receipt link the failed run to its development predecessor?",
        "What must be excluded from a D1 acceleration claim?",
        "Can a later successful run retroactively change this failure record?",
        "Does preserved evidence imply a successful experiment?",
        "Which record prevents promotion of the failed Backblaze run?",
        "What additional evidence would a positive D1 claim require?"
      ],
      "routes_to_records": [
        "VXI-BDAS-BACKBLAZE-D1-7135360-WORKER-FAILED-v1"
      ],
      "default_answer_boundary": "The D1 final state is worker failure. The supplied final record reports qualification and locked outer unopened and no production promotion. No successful performance result can be inferred from this run."
    },
    {
      "context_id": "reviewed_agent_discovery_versus_identity",
      "plain_language_trigger": "Does discovering an agent establish its identity or permissions?",
      "near_questions": [
        "Does an Agent Card authenticate a workload?",
        "Can workload identity replace an agent capability review?",
        "What evidence links discovery to an authorised action?",
        "How should agent capability and identity records be combined?",
        "Can a buyer request a receipt covering discovery and permissions?",
        "Does a recognised agent identity prove its advertised skills?"
      ],
      "routes_to_records": [
        "VXI-EXT-A2A-100-03-v1",
        "VXI-EXT-SPIFFE-01-v1",
        "VXI-EXT-OPA-02-v1"
      ],
      "default_answer_boundary": "A2A capability discovery, SPIFFE identity and OPA policy decisions address different questions. A declaration does not establish identity, and identity alone does not grant permission."
    },
    {
      "context_id": "reviewed_policy_management_versus_enforcement",
      "plain_language_trigger": "Does distributing policy prove an agent action was enforced correctly?",
      "near_questions": [
        "Can policy distribution prove a denied action was blocked?",
        "What links a policy revision to an enforced decision?",
        "Can decision logs establish the absence of bypasses?",
        "How should agent action context be matched to a policy receipt?",
        "Does control-plane visibility establish complete enforcement?",
        "What should a multi-record policy review deliver?"
      ],
      "routes_to_records": [
        "VXI-EXT-OPA-01-v1",
        "VXI-EXT-OPA-02-v1",
        "VXI-EXT-OPA-04-v1"
      ],
      "default_answer_boundary": "OPA management interfaces can distribute policy and report telemetry, while the integrating application applies decisions. A concrete enforcement claim needs the relevant revision, input, decision and action boundary."
    },
    {
      "context_id": "reviewed_provenance_versus_artifact_safety",
      "plain_language_trigger": "Do provenance and a valid signature prove an artifact is safe to execute?",
      "near_questions": [
        "Can signed provenance authorise an agent to execute a package?",
        "What remains unproven after artifact origin is verified?",
        "How should a receipt combine provenance and signer evidence?",
        "Does sandbox support make a signed dependency safe?",
        "Which sources separate authenticity from execution permission?",
        "Can a buyer request a scoped dependency reliance review?"
      ],
      "routes_to_records": [
        "VXI-EXT-SLSA-12-PROV-01-v1",
        "VXI-EXT-SIGSTORE-03-v1",
        "VXI-EXT-SIGSTORE-BUNDLE-01-v1",
        "VXI-EXT-GVISOR-01-v1"
      ],
      "default_answer_boundary": "Provenance and signature verification address origin, production and authenticity within their scope. They do not establish artifact harmlessness or authorise execution. The buyer's intended use needs separate review."
    },
    {
      "context_id": "reviewed_bdas_selector_correctness_and_fallback",
      "plain_language_trigger": "Which BDAS evidence distinguishes selective correctness, safe fallback and run failure?",
      "near_questions": [
        "BDAS selector correctness",
        "Does zero error under full fallback prove selective execution?",
        "How should consumed pump evidence be compared with fresh refusal outcomes?",
        "Can a failed campaign inherit correctness from another BDAS run?",
        "Which records support a bounded cross-workload BDAS receipt?",
        "What evidence distinguishes correctness from workload reduction?"
      ],
      "routes_to_records": [
        "VXI-BDAS-20261002-PUMP-E2C-7022048-CONSUMED-ENGINEERING-SELECTIVE-v1",
        "VXI-BDAS-20260902-N1-6256446-WIND-SCADA-PORTFOLIO-SAFE-REFUSAL-v1",
        "VXI-BDAS-20260824-M4B-6111326-CENTRIFUGE-EXTERNAL-SAFE-REFUSAL-v1",
        "VXI-BDAS-BACKBLAZE-D1-7135360-WORKER-FAILED-v1"
      ],
      "default_answer_boundary": "PUMP-E2C preserves bounded consumed-data selective evidence. N1 and M4B preserve full-processing refusal outcomes. Backblaze D1 reports worker failure. These states cannot be combined into a general performance claim."
    },
    {
      "context_id": "reviewed_cedar_policy_decisions",
      "plain_language_trigger": "Does using Cedar establish that an agent's actions are authorised?",
      "near_questions": [
        "What role can Cedar play in authorising agent actions?",
        "Does installing Cedar enforce every application action?",
        "Which evidence links a Cedar decision to execution?",
        "Can a policy engine establish business permission by itself?",
        "When does a Cedar integration need an enforcement review?",
        "Does a Cedar policy replace a user's approval?",
        "What must be checked before relying on Cedar output?",
        "Can a Cedar decision justify an agent purchase?",
        "How should a receipt describe an untested Cedar integration?",
        "Does a policy language prove all access rules are complete?",
        "Which application boundary consumes the Cedar result?",
        "What is still unknown after choosing Cedar?"
      ],
      "routes_to_records": [
        "VXI-EXT-CEDAR-01-v1"
      ],
      "default_answer_boundary": "Cedar provides a language and engine for authorization decisions. Correct policy, request data and application enforcement still need deployment evidence."
    },
    {
      "context_id": "reviewed_cedar_request_context",
      "plain_language_trigger": "What context does a Cedar authorization request need?",
      "near_questions": [
        "Who is the principal in a Cedar request?",
        "How is an agent action represented for Cedar?",
        "Why must the requested resource be identified?",
        "What happens if a policy request describes the wrong object?",
        "Can valid request structure hide inaccurate context?",
        "Which identity source supports the principal value?",
        "How can a buyer explain a Cedar request boundary?",
        "Should a receipt record the action and resource?",
        "Does a request context prove a user's intent?",
        "Which facts are needed before reviewing a Cedar decision?",
        "Can an agent select its own asserted permissions?",
        "What distinguishes request data from permission evidence?"
      ],
      "routes_to_records": [
        "VXI-EXT-CEDAR-02-v1"
      ],
      "default_answer_boundary": "Cedar requests identify the principal, action, resource and context. A correctly shaped request does not prove that these values accurately represent the intended operation."
    },
    {
      "context_id": "reviewed_cedar_deny_and_error_boundary",
      "plain_language_trigger": "Does Cedar's default denial mean every policy error denies the whole request?",
      "near_questions": [
        "Does a matching Cedar forbid override a permit?",
        "What does Cedar do when no permit is satisfied?",
        "Can Cedar allow a request while reporting a policy error?",
        "Is skip-on-error the same as deny-on-error?",
        "Why should an agent inspect Cedar diagnostics?",
        "Can an invalid forbid be assumed to protect a resource?",
        "What evidence supports a default-deny claim?",
        "How should a receipt state Cedar error limitations?",
        "Which policy actually determined an authorization result?",
        "Does a denied request establish that every policy ran correctly?",
        "Can a valid permit coexist with an erroneous policy?",
        "What prevents an overclaim about Cedar guardrails?"
      ],
      "routes_to_records": [
        "VXI-EXT-CEDAR-03-v1"
      ],
      "default_answer_boundary": "Cedar denies when no permit applies, and a satisfied forbid overrides a permit. Policies that error are skipped; error handling must not be described as unconditional denial."
    },
    {
      "context_id": "reviewed_cedar_schema_validation",
      "plain_language_trigger": "Does Cedar policy validation prove that the policy expresses the intended permissions?",
      "near_questions": [
        "What does Cedar schema validation check?",
        "Does a valid Cedar policy grant only intended permissions?",
        "Should policies be rechecked after a schema change?",
        "Can a stale validation result support a new entity model?",
        "Which versions belong in a Cedar validation receipt?",
        "Does policy validation prove that live inputs match the schema?",
        "How does a schema review differ from a permission review?",
        "Can well-formed Cedar policy still be wrong for the business?",
        "What context is needed to review a policy validation claim?",
        "Does changing an action type affect earlier validation?",
        "Which evidence is missing from a syntax-only policy check?",
        "Can validation replace application access tests?"
      ],
      "routes_to_records": [
        "VXI-EXT-CEDAR-04-v1"
      ],
      "default_answer_boundary": "Cedar can check policies against an application schema for consistency. Schema changes can invalidate earlier checks; validation alone does not establish the intended permission model."
    },
    {
      "context_id": "reviewed_cvss_severity_context",
      "plain_language_trigger": "Can a CVSS score alone determine a buyer's operational risk?",
      "near_questions": [
        "Is CVSS severity the same as business risk?",
        "Which CVSS metric groups depend on environment?",
        "Do Supplemental CVSS values alter the score?",
        "Can a base score determine an agent's patch priority?",
        "What context should accompany vulnerability severity?",
        "Does CVSS establish whether a vulnerable feature is reachable?",
        "Why might two deployments need different risk reviews?",
        "What belongs beside a severity score in a receipt?",
        "Can an agent rely on an old threat assessment?",
        "Does a numerical severity replace an asset inventory?",
        "Which assumptions need checking before using CVSS?",
        "What does a score leave unknown about operations?"
      ],
      "routes_to_records": [
        "VXI-EXT-CVSS-40-01-v1"
      ],
      "default_answer_boundary": "CVSS v4.0 separates Base, Threat, Environmental and Supplemental metrics. Supplemental values add context without changing the score; a severity score alone does not establish local risk."
    },
    {
      "context_id": "reviewed_cvss_vector_traceability",
      "plain_language_trigger": "What does a CVSS vector add to a published score?",
      "near_questions": [
        "Why retain the CVSS vector alongside the score?",
        "Can two similar scores reflect different metric choices?",
        "Which evidence makes a severity assessment traceable?",
        "Does a syntactically valid vector prove accurate scoring?",
        "What should an agent request when only a score is provided?",
        "Can a receipt preserve the original scoring assumptions?",
        "Does a vector identify the CVSS version?",
        "What must be checked when reusing a vulnerability rating?",
        "Can a reported score be reviewed without its inputs?",
        "How does vector traceability differ from scoring correctness?",
        "Should a downstream report retain the score's source?",
        "What prevents a severity number from losing context?"
      ],
      "routes_to_records": [
        "VXI-EXT-CVSS-40-02-v1"
      ],
      "default_answer_boundary": "A CVSS vector records the metric choices behind a score. FIRST's publication guidance calls for both score and vector; this makes the assessment inspectable without proving its inputs correct."
    },
    {
      "context_id": "reviewed_cvss_safety_context",
      "plain_language_trigger": "Does an omitted CVSS Safety value mean there are no safety impacts?",
      "near_questions": [
        "Does missing CVSS Safety information mean safe?",
        "Can a vulnerability score certify an industrial system?",
        "What does Not Defined leave unresolved for safety?",
        "Why should an agent preserve an unassessed safety state?",
        "Can an ordinary vulnerability score replace a safety review?",
        "Which deployment facts affect safety relevance?",
        "What should a receipt say when safety has not been assessed?",
        "Does a low severity automatically rule out human impact?",
        "Who supplied the safety-related assessment context?",
        "Can omitted safety metadata justify deployment?",
        "What is the boundary of CVSS safety information?",
        "How should unknown safety impact be represented?"
      ],
      "routes_to_records": [
        "VXI-EXT-CVSS-40-04-v1"
      ],
      "default_answer_boundary": "CVSS v4.0 includes safety-related context. An omitted Supplemental Safety assessment does not establish absence of safety impacts; deployment-specific consequences require separate assessment."
    },
    {
      "context_id": "reviewed_osv_known_vulnerability_query",
      "plain_language_trigger": "Does an empty OSV query prove a package has no vulnerabilities?",
      "near_questions": [
        "What does an empty OSV result establish?",
        "Can OSV query a specific commit?",
        "How can an agent look up a package version?",
        "Does a batch query certify all dependencies?",
        "What if the package name or ecosystem is wrong?",
        "Which identifiers should accompany an OSV receipt?",
        "Does known-vulnerability coverage include undisclosed flaws?",
        "Can a query result establish runtime reachability?",
        "Why preserve the time of a vulnerability lookup?",
        "What additional evidence links a lookup to a deployed build?",
        "Does a clean database result make an artifact safe?",
        "How should missing vulnerability matches be described?"
      ],
      "routes_to_records": [
        "VXI-EXT-OSV-API-01-v1"
      ],
      "default_answer_boundary": "OSV provides queries for known vulnerabilities by package version or commit, including batches. No returned match does not prove absence of unknown issues or correct identification of the deployed artifact."
    },
    {
      "context_id": "reviewed_osv_advisory_provenance",
      "plain_language_trigger": "What does OSV aggregation establish about a vulnerability advisory?",
      "near_questions": [
        "Where does an OSV advisory originate?",
        "Does aggregation independently verify every vulnerability report?",
        "Why inspect affected-version ranges?",
        "Can two advisory identifiers describe the same issue?",
        "What source should a vulnerability receipt preserve?",
        "Does an advisory prove a buyer runs the affected version?",
        "Which evidence connects a database record to an artifact?",
        "Can a common format remove uncertainty in source data?",
        "How should an agent distinguish an advisory from an incident?",
        "Does advisory publication mean exploitation was observed locally?",
        "What changes when an upstream advisory is revised?",
        "How should source uncertainty survive aggregation?"
      ],
      "routes_to_records": [
        "VXI-EXT-OSV-API-03-v1"
      ],
      "default_answer_boundary": "OSV aggregates advisories in a shared vulnerability format. The originating advisory and affected-version mapping remain relevant; aggregation does not establish that a particular deployment is affected."
    },
    {
      "context_id": "reviewed_osv_import_quality_boundary",
      "plain_language_trigger": "Are OSV import findings accepted vulnerability results?",
      "near_questions": [
        "What does an OSV import finding mean?",
        "Is an import-quality failure a confirmed vulnerability?",
        "Why preserve the experimental endpoint label?",
        "Can an ingestion issue be counted as an accepted advisory?",
        "What evidence separates bad input from an affected package?",
        "Should an agent recheck an experimental OSV interface?",
        "Can rejected records justify a customer security claim?",
        "How should a receipt label import-time quality findings?",
        "Does a successful download mean a record was accepted?",
        "What additional review is needed after an import finding?",
        "Can an experimental response be assumed stable?",
        "Which source record explains a vulnerability ingestion issue?"
      ],
      "routes_to_records": [
        "VXI-EXT-OSV-API-04-v1"
      ],
      "default_answer_boundary": "OSV documents an experimental endpoint for records that fail import-time quality checks. Such findings describe ingestion issues and must not be treated as accepted vulnerability results or a stable interface guarantee."
    },
    {
      "context_id": "reviewed_osv_scanner_input_coverage",
      "plain_language_trigger": "Does scanning a lockfile or SBOM establish complete deployment coverage?",
      "near_questions": [
        "Can OSV-Scanner inspect a software bill of materials?",
        "Which lockfile was used for a vulnerability scan?",
        "Does scanning a repository cover every deployed component?",
        "What if an SBOM omits a runtime dependency?",
        "How does scanner input affect the meaning of a clean result?",
        "Can an agent rely on an outdated inventory scan?",
        "What should a scan receipt identify about its input?",
        "Does directory scanning establish production coverage?",
        "How is the scanned artifact linked to the release?",
        "Can supported file formats imply complete analysis?",
        "Which dependencies were outside the submitted scan scope?",
        "What evidence is needed before claiming full scan coverage?"
      ],
      "routes_to_records": [
        "VXI-EXT-OSV-06-v1"
      ],
      "default_answer_boundary": "OSV-Scanner documents SBOM, lockfile and directory inputs. The result depends on what the supplied input represents; supported input formats do not establish a complete inventory of the running system."
    },
    {
      "context_id": "reviewed_spdx_standard_versus_certification",
      "plain_language_trigger": "Does publishing an SPDX document certify the software it describes?",
      "near_questions": [
        "Does an SPDX label certify a package?",
        "What does SPDX standards status apply to?",
        "Can a standard format contain incomplete inventory?",
        "Does an SPDX document prove license compliance?",
        "Why record the SPDX version in an evidence receipt?",
        "Can an agent equate document conformance with software safety?",
        "Which evidence supports the contents of an SPDX file?",
        "Does using an international standard verify a supplier?",
        "What remains unproven after generating an SPDX document?",
        "Should a buyer review the inventory producer and scope?",
        "Can SPDX presence replace dependency review?",
        "What is the limit of a standards-based inventory claim?"
      ],
      "routes_to_records": [
        "VXI-EXT-SPDX-30-02-v1"
      ],
      "default_answer_boundary": "SPDX is an open specification for exchanging supply-chain information. Its standards status does not certify a submitted document's completeness, license conclusions or the safety of its software."
    },
    {
      "context_id": "reviewed_scorecard_project_practice_boundary",
      "plain_language_trigger": "Does an OpenSSF Scorecard result guarantee that a dependency is safe?",
      "near_questions": [
        "What does an OpenSSF Scorecard result measure?",
        "Can a high project score approve a dependency automatically?",
        "Which revision was assessed by Scorecard?",
        "Does project hygiene prove artifact safety?",
        "What if a relevant Scorecard check was not run?",
        "How should a receipt preserve check-level context?",
        "Does an aggregate score hide individual check results?",
        "Can an old Scorecard result describe a new release?",
        "What additional evidence is needed before using a dependency?",
        "Does Scorecard replace testing the intended workload?",
        "Can an agent treat project scores as certification?",
        "How does a practice assessment differ from vulnerability evidence?"
      ],
      "routes_to_records": [
        "VXI-EXT-OPENSSF-SCORECARD-01-v1"
      ],
      "default_answer_boundary": "OpenSSF Scorecard uses automated checks to assess project security practices. A result is evidence about those checks, not a guarantee that an artifact is safe or suitable for a buyer."
    },
    {
      "context_id": "reviewed_oauth_security_bcp_scope",
      "plain_language_trigger": "Does citing RFC 9700 establish that an OAuth deployment is secure?",
      "near_questions": [
        "What does RFC 9700 contribute to an OAuth review?",
        "Does a standards reference prove secure OAuth configuration?",
        "Which OAuth flow is being assessed?",
        "Can an agent claim conformance without implementation evidence?",
        "Does OAuth support alone verify token handling?",
        "What should a buyer supply for an OAuth scope review?",
        "Are security recommendations equivalent to a passed test?",
        "Can an OAuth guideline authorise an agent purchase?",
        "Which deployment facts determine relevant requirements?",
        "Does using a library prove every control is enabled?",
        "What belongs in a bounded OAuth evidence receipt?",
        "How should an untested OAuth claim be worded?"
      ],
      "routes_to_records": [
        "VXI-EXT-RFC9700-01-v1"
      ],
      "default_answer_boundary": "RFC 9700 documents OAuth 2.0 security best practices and updates earlier guidance. Citation alone does not demonstrate that a deployment implements the relevant requirements."
    },
    {
      "context_id": "reviewed_oauth_public_client_pkce",
      "plain_language_trigger": "What does RFC 9700 require for public clients using authorization codes?",
      "near_questions": [
        "Must public OAuth clients using authorization codes use PKCE?",
        "Does advertised PKCE support prove it is enforced?",
        "Which grant type does the public-client requirement cover?",
        "Can an agent infer PKCE configuration from an SDK name?",
        "What evidence distinguishes support from active protection?",
        "How should a receipt scope a PKCE claim?",
        "Does PKCE alone establish safe token storage?",
        "Why identify whether a client is public or confidential?",
        "Can a successful login prove all OAuth requirements?",
        "What remains unknown without flow validation?",
        "Does an unused security feature protect an integration?",
        "What context is needed for a public-client OAuth review?"
      ],
      "routes_to_records": [
        "VXI-EXT-RFC9700-02-v1"
      ],
      "default_answer_boundary": "RFC 9700 requires PKCE for public clients using the authorization code grant. A claim of PKCE support still needs evidence that the deployed flow enforces it."
    },
    {
      "context_id": "reviewed_oauth_sender_constrained_tokens",
      "plain_language_trigger": "What can sender-constrained access tokens support in an OAuth security claim?",
      "near_questions": [
        "What is the purpose of sender-constrained OAuth tokens?",
        "Does issuing a constrained token prove the resource server checks it?",
        "Can a bearer token be described as proof-bound without evidence?",
        "What claim can an agent make about token replay resistance?",
        "Which deployment component verifies token possession?",
        "Does token binding remove every account compromise risk?",
        "What evidence is needed for a DPoP deployment claim?",
        "How should a receipt distinguish a recommendation from implementation?",
        "Can possession controls replace application permissions?",
        "What assumptions matter when signing key material is compromised?",
        "Does protocol support prove end-to-end enforcement?",
        "Why preserve the threat model for token protection?"
      ],
      "routes_to_records": [
        "VXI-EXT-RFC9700-03-v1"
      ],
      "default_answer_boundary": "RFC 9700 recommends sender-constraining access tokens to reduce misuse of stolen tokens. A deployment claim needs evidence that the relevant proof is checked; the mechanism is not a universal compromise guarantee."
    },
    {
      "context_id": "reviewed_oauth_server_metadata",
      "plain_language_trigger": "Does OAuth server metadata prove the deployment is correctly configured?",
      "near_questions": [
        "What does OAuth authorization server metadata provide?",
        "Can advertised features differ from enforced behavior?",
        "Why retain the issuer when reviewing metadata?",
        "Does automatic configuration eliminate all misconfiguration?",
        "What evidence connects metadata to the intended server?",
        "Should an agent recheck cached OAuth metadata?",
        "Can a metadata document certify a login flow?",
        "How should a receipt identify a metadata snapshot?",
        "Does publishing endpoints establish permission to use them?",
        "Which client behavior matters when metadata changes?",
        "What remains unverified after discovering an OAuth server?",
        "Can metadata availability replace integration checks?"
      ],
      "routes_to_records": [
        "VXI-EXT-RFC9700-04-v1"
      ],
      "default_answer_boundary": "RFC 9700 recommends publishing authorization server metadata and using it where available. Metadata supports configuration but does not prove that advertised controls are correctly enforced."
    },
    {
      "context_id": "reviewed_cyclonedx_schema_identification",
      "plain_language_trigger": "Do CycloneDX format and version fields establish that a BOM is complete?",
      "near_questions": [
        "What does the CycloneDX format field identify?",
        "Does a specification version prove complete inventory?",
        "Can an agent trust a BOM because it parses successfully?",
        "Which schema version should a BOM receipt record?",
        "Does a valid document prove the components are accurate?",
        "How do declared format and verified contents differ?",
        "Can a BOM omit dependencies while remaining structurally valid?",
        "What scope should accompany a CycloneDX file?",
        "Does schema conformance establish deployment safety?",
        "Which producer created the inventory being reviewed?",
        "What evidence supports the BOM's component list?",
        "How should an unverified inventory be described?"
      ],
      "routes_to_records": [
        "VXI-EXT-CYCLONEDX-17-01-v1"
      ],
      "default_answer_boundary": "CycloneDX 1.7 defines format and specification-version identifiers. They identify the declared representation; completeness and correctness of the described inventory require separate evidence."
    },
    {
      "context_id": "reviewed_cyclonedx_document_revisions",
      "plain_language_trigger": "What do CycloneDX serial numbers and BOM versions establish?",
      "near_questions": [
        "How can a receipt distinguish CycloneDX BOM revisions?",
        "Is the BOM version the same as a software version?",
        "Does a serial number prove who produced an inventory?",
        "Why preserve a BOM's revision when comparing claims?",
        "Can a newer BOM contain incorrect component data?",
        "What changes should prompt a document version update?",
        "Does document identity prove artifact identity?",
        "How should an agent handle two revisions with one serial number?",
        "Which release does the reviewed BOM describe?",
        "Can a revision counter certify an inventory update?",
        "What evidence connects a revised BOM to a new build?",
        "Why should a paid review record the exact BOM revision?"
      ],
      "routes_to_records": [
        "VXI-EXT-CYCLONEDX-17-02-v1"
      ],
      "default_answer_boundary": "CycloneDX 1.7 recommends unique serial numbers and increasing a BOM's version when it is modified. These identify document revisions; they do not prove the truth of a revised inventory."
    },
    {
      "context_id": "reviewed_cyclonedx_inventory_relationships",
      "plain_language_trigger": "Can CycloneDX represent service and dependency relationships as well as components?",
      "near_questions": [
        "Can a CycloneDX inventory describe external services?",
        "Does a dependency graph prove every relationship was discovered?",
        "Which transitive dependencies are included in a BOM?",
        "What distinguishes an inventory model from observed deployment facts?",
        "Can an agent infer completeness from relationship support?",
        "How should a receipt state missing dependency coverage?",
        "Does a listed service prove that its boundary was tested?",
        "What context explains a component-to-service relationship?",
        "Can one inventory describe multiple dependency types?",
        "What should a buyer provide for a dependency-coverage review?",
        "Does a model's expressiveness guarantee accurate data?",
        "How should unknown inventory completeness be preserved?"
      ],
      "routes_to_records": [
        "VXI-EXT-CDX-17-05-v1"
      ],
      "default_answer_boundary": "CycloneDX can describe components, services and dependency relationships. Representation support does not establish that a supplied BOM captures every direct or transitive relationship."
    },
    {
      "context_id": "reviewed_policy_validation_and_enforcement",
      "plain_language_trigger": "Does policy validation prove an agent's action was enforced correctly?",
      "near_questions": [
        "Can Cedar validation replace an OPA enforcement check?",
        "What evidence connects policy intent to an executed action?",
        "Does a permission decision prove that an application obeyed it?",
        "How should agents distinguish valid policy from enforced policy?",
        "Which controls matter between a policy check and a tool call?",
        "What should a multi-record authorization receipt preserve?"
      ],
      "routes_to_records": [
        "VXI-EXT-CEDAR-04-v1",
        "VXI-EXT-CEDAR-03-v1",
        "VXI-EXT-OPA-02-v1"
      ],
      "default_answer_boundary": "Policy validation, a returned decision and application enforcement are different evidence states. Review the schema, request data, diagnostics and execution boundary together."
    },
    {
      "context_id": "reviewed_identity_token_and_permission",
      "plain_language_trigger": "Do workload identity and OAuth protection grant permission to act?",
      "near_questions": [
        "Can SPIFFE identity plus OAuth support authorise a purchase?",
        "How does token possession differ from action permission?",
        "What evidence links workload identity to an authorized operation?",
        "Does a secure login prove an agent may spend?",
        "Which identity and permission boundaries should a receipt separate?",
        "Can sender-constrained tokens replace application policy?"
      ],
      "routes_to_records": [
        "VXI-EXT-SPIFFE-01-v1",
        "VXI-EXT-RFC9700-03-v1",
        "VXI-EXT-CEDAR-01-v1"
      ],
      "default_answer_boundary": "Workload identity, token protection and action authorization support different claims. None alone establishes user intent, spending permission or correct enforcement across the complete flow."
    },
    {
      "context_id": "reviewed_inventory_and_vulnerability_coverage",
      "plain_language_trigger": "Does a valid SBOM and an empty vulnerability lookup prove a release is safe?",
      "near_questions": [
        "Can a CycloneDX document and OSV lookup certify a release?",
        "What if an unlisted dependency is absent from a scan?",
        "How should a receipt link a BOM revision to vulnerability results?",
        "Does SPDX conformance imply complete OSV coverage?",
        "Which evidence connects a package inventory to a running deployment?",
        "What remains unknown after scanning a valid SBOM?"
      ],
      "routes_to_records": [
        "VXI-EXT-CYCLONEDX-17-02-v1",
        "VXI-EXT-SPDX-30-02-v1",
        "VXI-EXT-OSV-API-01-v1",
        "VXI-EXT-OSV-06-v1"
      ],
      "default_answer_boundary": "An inventory format identifies represented content, and a lookup reports known matches for its inputs. Check inventory completeness, artifact mapping and lookup date before describing coverage; neither result guarantees safety."
    },
    {
      "context_id": "reviewed_project_scores_and_severity",
      "plain_language_trigger": "Can a project practice score replace vulnerability severity and deployment review?",
      "near_questions": [
        "Is an OpenSSF Scorecard result comparable to a CVSS score?",
        "Can a high project score cancel a vulnerability finding?",
        "How should an agent combine practice and severity evidence?",
        "Does good repository hygiene remove local exposure?",
        "Which assessments belong in a dependency review receipt?",
        "Can aggregate project scores determine operational risk?"
      ],
      "routes_to_records": [
        "VXI-EXT-OPENSSF-SCORECARD-01-v1",
        "VXI-EXT-CVSS-40-01-v1",
        "VXI-EXT-OSV-API-03-v1"
      ],
      "default_answer_boundary": "Project checks, vulnerability severity and deployment context answer different questions. Preserve each source and assessment scope instead of combining them into an unsupported safety conclusion."
    }
  ],
  "public_record_count": 122,
  "agentic_route_count": 108,
  "near_question_hook_count": 1528,
  "near_question_counting": {
    "method": "unique_normalised_near_question_text",
    "scope": [
      "record near_questions",
      "agentic route near_questions",
      "context near_questions"
    ],
    "normalisation": "Lowercase ASCII letters and digits; punctuation and whitespace collapse to a single space.",
    "exclusions": [
      "Canonical questions",
      "Duplicate index summaries",
      "Repeated question wording across surfaces"
    ],
    "note": "Counts distinct question wording, not unique intents, verified answers or demand."
  }
}
