Repository navigation
Import agent-evidence-vocabulary through the CRE links in its source #1145
Description
Hi @robvanderveer, @imran-siddique asked for agent-evidence-vocabulary to come to you as its own standard.
It is a versioned registry of terms for claims about an AI agent's execution, and it uses the self-maintaining method from your contributing guide. The terms below carry an opencre list of full CRE URLs in vocabulary.yaml at v0.4.0, and each link has a fit and a one-line basis. docs/OPENCRE.md defines the fit values and lists every link.
| term | CRE | fit | what the two share |
|---|---|---|---|
| observation_vantage | 026-280 Securely transfer logs (remotely) | partial | the record of an execution is kept where the executed party cannot alter it |
| containment_posture | 515-021 Sandbox, containerize and/or isolate applications at the network level | structural | the term records the network isolation the artifact actually ran inside |
| coverage_denominator | 433-442 Verification | partial | a test result names the population it assessed (NIST 800-53 SA-11) |
| revision_reason | 757-271 Use source code control system with change traceability and access control | partial | every change carries its reason, here for a published record's derived values |
| admission_decision | 112-648 Change management | structural | one recorded admit or reject decision per proposed change to an agent's harness (its prompt, procedures, tool-call guards and tools) |
| admission_gate | 124-564 Configuration Management | structural | the checks a harness change passes before admission (NIST 800-53 CM-3, CM-4) |
| admission_gate | 547-824 AI model performance validation | partial | held-out and no-regression runs validate the changed agent's behaviour |
| replay_coverage | 433-442 Verification | partial | whether a replay checked every recorded trace |
| authority_change | 524-603 Limit modification of access controls to specifically authorized actors/users | structural | adding a tool or removing a guard needs a human-signed approval of the exact candidate |
| authority_change | 220-442 Model action privilege minimization | partial | a candidate harness's tool allowlist cannot grow past that of the harness it replaces without approval |
I derived each link from the term's definition against the 522 live CREs, reading each candidate's linked standards. Nine terms have no CRE that states their requirement, and that page gives each reason: observation_directness, witness_scope, field_evidence_partition, issuance_time_basis, does_not_assert, claim_subject, result, evaluation_mode and replay_snapshot. I withdraw the three links I proposed under 307-507: its standards (ASVS V10.3.2, SSDF PS.2.1) cover the origin and integrity of loaded code.
Once you acknowledge this issue in a comment, I will open a parser PR under application/utils/external_project_parsers that reads vocabulary.yaml at release tags from v0.4.0. The vocabulary's CI already refuses a malformed link, a CRE URL anywhere else in the file and an id that opencre.org does not return.
Activity
V-2007-P commentedon Oct 14, 2026
Hi, I spent some time going through the existing parser implementation to understand how this could fit into OpenCRE, and I found a few things that might be useful for this issue.
I noticed that
dsomm.pyalready handles YAML-based imports usingyaml.safe_load(), andcapec_parser.pyextracts the version from the external source and passes it todefs.Standard. I also looked atcheatsheets_workstream_f.py, where CRE links are resolved through the cache, and missing CRE IDs are handled without breaking the import.From what I could see, there are already some good examples in the codebase that could be used as a reference for this importer, rather than introducing a completely different approach.
I also had a look at the existing parser tests, particularly
dsomm_parser_test.pyandmisc_tools_parser_test.py. It seems like we could follow the same testing approach for checking YAML parsing, version handling, CRE link resolution, and cases where a referenced CRE doesn't exist in the cache.I saw your note about opening the parser PR once the issue is acknowledged, so I don't want to duplicate the implementation you're already planning. However, I'd be happy to contribute if there's a part I can take ownership of, whether that's the CLI integration in
cre.pyandapplication/cmd/cre_main.py, or adding focused tests around the importer.Would either of those be useful, or would you prefer to keep the parser and its integration together in your PR? I'm happy to follow whichever approach works best for the project.
astrogilda commentedon Oct 24, 2026
Hi @V-2007-P, thanks for going through the existing parsers so carefully. The parser, the CLI flag and the tests are now together in #1173, and the tests follow the dsomm_parser_test.py approach you suggested.
A review there would help a lot, especially a run of
--agent_evidence_vocabulary_inagainst a populated cache. So far I have only run the unit tests and counted the links in the release file.