|
| 1 | +{ |
| 2 | + "$schema": "https://aveproject.org/schema/crosswalk-1.0.0.schema.json", |
| 3 | + "source": { |
| 4 | + "standard": "AVE", |
| 5 | + "version": "1.1.0", |
| 6 | + "url": "https://aveproject.org", |
| 7 | + "record_count": 80, |
| 8 | + "commit": "1e29789e4941b6c1c2435508dbf3c245eedc8d04" |
| 9 | + }, |
| 10 | + "target": { |
| 11 | + "registry": "agent-evidence-vocabulary", |
| 12 | + "version": "0.2.0", |
| 13 | + "license": "CC0-1.0", |
| 14 | + "url": "https://github.com/probityai/agent-evidence-vocabulary", |
| 15 | + "registry_file": "vocabulary.yaml", |
| 16 | + "term_count": 8, |
| 17 | + "checked_against_live_file": "2026-09-15", |
| 18 | + "commit": "66177d65690e9d7eb7e4ff59df8f91792a90735b" |
| 19 | + }, |
| 20 | + "generated": "2026-09-15", |
| 21 | + "note": "A field-level crosswalk between AVE's evidence-provenance properties and the agent-evidence-vocabulary registry, which names the axes an execution-evidence claim is read on: who observed the execution, how directly, and what the claim leaves out. The unit is a schema property rather than a category, because the two sides describe different things: AVE enumerates behavioral vulnerability classes and the registry names the provenance axes any claim about an execution carries. They meet at exactly one place, which is how AVE says where its evidence came from. Read coverage before trusting a row: none of the 80 records carries evidence_vantage, evidence_method or verification_basis. All three are optional in schema v1.1.0 and all three read absent on every record at the commit above, verified by fetching each record file rather than by reading the schema. Every mapping below is therefore evidence: inferred, established by comparing two schema definitions, and none is evidence: emitted. A row moves to emitted when a record carries the field and a reviewer can fetch it.", |
| 22 | + "mappings": [ |
| 23 | + { |
| 24 | + "ave_field": "evidence_vantage", |
| 25 | + "ave_values": [ |
| 26 | + "substrate", |
| 27 | + "artifact" |
| 28 | + ], |
| 29 | + "registry_term": "observation_vantage", |
| 30 | + "registry_section": "evidence_dimensions", |
| 31 | + "registry_values": [ |
| 32 | + "substrate", |
| 33 | + "artifact" |
| 34 | + ], |
| 35 | + "match_type": "exact", |
| 36 | + "evidence": "inferred", |
| 37 | + "notes": "Value sets are identical and so is the composition rule: both take the weakest input, so a claim mixing substrate and artifact observations inherits artifact. The two definitions were written independently and reached the same two-value split, which is the case for mapping them exact rather than structural. The registry adds one consumer-side requirement AVE's schema does not state, that a consumer with no policy-pinned substrate root must treat a substrate row as unattested rather than infer the root from the claim." |
| 38 | + }, |
| 39 | + { |
| 40 | + "ave_field": "evidence_method", |
| 41 | + "ave_values": [ |
| 42 | + "intercepted", |
| 43 | + "reconstructed" |
| 44 | + ], |
| 45 | + "registry_term": "observation_directness", |
| 46 | + "registry_section": "evidence_dimensions", |
| 47 | + "registry_values": [ |
| 48 | + "intercepted", |
| 49 | + "reconstructed" |
| 50 | + ], |
| 51 | + "match_type": "exact", |
| 52 | + "evidence": "inferred", |
| 53 | + "notes": "Identical value sets, identical weakest-input composition, and both treat reconstructed as the floor a producer may always truthfully state. AVE's schema says an absent value reads as reconstructed; the registry does not state a default, so a producer emitting both sides should write the value rather than rely on either reading." |
| 54 | + }, |
| 55 | + { |
| 56 | + "ave_field": "verification_basis", |
| 57 | + "ave_values": [ |
| 58 | + "substrate_intercepted", |
| 59 | + "substrate_reconstructed", |
| 60 | + "artifact_intercepted", |
| 61 | + "artifact_reconstructed" |
| 62 | + ], |
| 63 | + "registry_term": "observation_vantage + observation_directness", |
| 64 | + "registry_section": "evidence_dimensions", |
| 65 | + "match_type": "structural", |
| 66 | + "evidence": "inferred", |
| 67 | + "notes": "The four values are the product of the two axes above, which is what scripts/write_verification_basis.py composes. The registry keeps the axes separate and does not define the composed term, so this is a structural correspondence rather than a term pairing: a consumer holding an AVE verification_basis can split it into the two registry axes without loss, and a consumer holding both registry values can compose the AVE value without loss." |
| 68 | + }, |
| 69 | + { |
| 70 | + "ave_field": "evidence_basis_engines", |
| 71 | + "ave_values": [ |
| 72 | + "pattern", |
| 73 | + "yara", |
| 74 | + "semgrep", |
| 75 | + "llm", |
| 76 | + "sandbox", |
| 77 | + "magika", |
| 78 | + "external_authority" |
| 79 | + ], |
| 80 | + "registry_term": "observation_vantage", |
| 81 | + "registry_section": "evidence_dimensions", |
| 82 | + "match_type": "partial", |
| 83 | + "evidence": "inferred", |
| 84 | + "notes": "One value carries vantage information and the rest do not. external_authority means a party outside the observed artifact answered, which is the substrate side of the registry's axis; sandbox observes execution and is the other candidate. pattern, yara, semgrep, llm and magika all read the artifact's own bytes, so they sit on the artifact side. AVE's own schema already composes this field into verification_basis by weakest input, so the partial mapping is not a gap in AVE, it is the reason the composed field exists." |
| 85 | + } |
| 86 | + ], |
| 87 | + "gaps": [ |
| 88 | + { |
| 89 | + "side": "registry", |
| 90 | + "registry_term": "field_evidence_partition", |
| 91 | + "reason": "Declares which identity's signature backs which field inside one mixed claim. AVE records a vulnerability class rather than a signed claim, so there is no per-field signer to partition." |
| 92 | + }, |
| 93 | + { |
| 94 | + "side": "registry", |
| 95 | + "registry_term": "issuance_time_basis", |
| 96 | + "reason": "Distinguishes a timestamp anchored to a beacon from one the producer asserts. AVE records carry published and last_updated as editorial dates on the record, not as claims about when an execution was observed." |
| 97 | + }, |
| 98 | + { |
| 99 | + "side": "registry", |
| 100 | + "registry_term": "containment_posture", |
| 101 | + "reason": "Describes the network posture an execution ran under. AVE classifies component behavior independently of any one run's containment." |
| 102 | + }, |
| 103 | + { |
| 104 | + "side": "registry", |
| 105 | + "registry_term": "coverage_denominator", |
| 106 | + "reason": "States the population a claim was measured over. An AVE record is a class definition rather than a measurement, so it has no denominator to declare." |
| 107 | + }, |
| 108 | + { |
| 109 | + "side": "registry", |
| 110 | + "registry_term": "does_not_assert", |
| 111 | + "reason": "Carries, inside the signed bytes, what a claim deliberately leaves out. AVE has no signed-claim envelope for this to sit in; the nearest thing is prose in vulnerability_rationale." |
| 112 | + }, |
| 113 | + { |
| 114 | + "side": "registry", |
| 115 | + "registry_term": "result", |
| 116 | + "reason": "A recomputable outcome lattice over one execution: fail, degraded, pass_indirect, pass. AVE scores a class with AIVSS rather than recording an outcome, and the registry's own out-of-scope block rules out reading its lattice as a threshold anyway." |
| 117 | + }, |
| 118 | + { |
| 119 | + "side": "ave", |
| 120 | + "ave_field": "confidence_baseline", |
| 121 | + "reason": "A scanner's prior on a single-engine match. The registry's out-of-scope block excludes scored assessment, so there is deliberately no term for it and there will not be one." |
| 122 | + }, |
| 123 | + { |
| 124 | + "side": "ave", |
| 125 | + "ave_field": "detection_stage", |
| 126 | + "reason": "Says when in a component's lifecycle a class is detectable. The registry has no lifecycle axis." |
| 127 | + }, |
| 128 | + { |
| 129 | + "side": "ave", |
| 130 | + "ave_field": "detection_layer", |
| 131 | + "reason": "Says which layer of a component a detector reads. The registry's vantage axis is about the relation between observer and observed, not about which layer was read, and the two are orthogonal." |
| 132 | + }, |
| 133 | + { |
| 134 | + "side": "ave", |
| 135 | + "ave_field": "evidence_kind_default", |
| 136 | + "reason": "A scanner hint naming the detection technique. The registry names where a claim came from rather than how it was computed." |
| 137 | + } |
| 138 | + ], |
| 139 | + "coverage": { |
| 140 | + "registry_terms_total": 8, |
| 141 | + "registry_terms_mapped": 2, |
| 142 | + "registry_terms_structurally_covered": 1, |
| 143 | + "registry_terms_unmapped": 6, |
| 144 | + "ave_evidence_fields_total": 7, |
| 145 | + "ave_evidence_fields_mapped": 4, |
| 146 | + "ave_records_total": 80, |
| 147 | + "ave_records_carrying_any_mapped_field": 0, |
| 148 | + "what_the_counts_leave_out": "registry_terms_mapped counts observation_vantage and observation_directness. verification_basis covers the same two axes composed, so it is counted once as structural rather than twice, and registry_terms_unmapped plus the two mapped terms is 8. ave_records_carrying_any_mapped_field is 0 because evidence_vantage, evidence_method and verification_basis are absent from all 80 record files at the pinned commit, checked by fetching each file. evidence_basis_engines is present on records and is the partial row, so the zero describes the three composed fields rather than the whole mapping." |
| 149 | + } |
| 150 | +} |
0 commit comments