It can check
- Whether JSON parses and fields match the v1 rules
- Whether identity, digest format, claim boundary or index metadata is missing
- Whether deviations remain open, the decision is pending or one person self-reviews
Open engineering references · Local verification tool
Robotics Evidence Package Verifier
Check a FUURAA robotics evidence-package JSON locally in your browser for structure, identity, digest format, claim boundary, evidence index, deviations and independent review decision. The file is not uploaded to FUURAA.
Verification workspace
Load a manifest, then close every structural issue.
Choose a local JSON file, paste content, or load one of the three blank examples. Blank examples intentionally show incomplete fields so the review gates remain visible.
Privacy boundary: this tool does not submit, store or transmit the selected file. Continue to handle sensitive evidence under your organisation's rules.
Applicability boundary
This tool checks whether the manifest looks complete—not whether the evidence is true.
It cannot prove
- That indexed files exist, are untampered or match the declared digest
- That tests are valid, results reproducible, the robot safe or certification-ready
- That licences, third-party rights, signer identities or expert conclusions are valid
FUURAA analysisThe most useful role of automation is to reject structural incompleteness early, not to present a valid format as technical truth. The evidence chain can close only after a recipient recomputes real-file digests from a read-only copy, restores the environment, reviews raw records and signs an independent decision.
Standards and method sources
Verification rules connect to original specifications while preserving each source's own scope.
Internet Standard · Published December 2017IETF RFC 8259 · JSON Data Interchange Format
Return to the Open Robot Engineering Reference Library →Defines JSON grammar, values, objects, arrays and parser interoperability.
↗Informational RFC · Published 2020IETF RFC 8785 · JSON Canonicalization SchemeExplains why repeatable hashing requires an invariant JSON representation.
↗Final NIST publication · Published February 2022NIST SP 800-218 · Secure Software Development Framework 1.1Provides a common vocabulary for secure development evidence and supplier–acquirer communication.
↗Approved specification · Approved specification · checked 4 August 2026SLSA v1.2 · ProvenanceFrames provenance as verifiable information about where, when and how an artifact was produced.
↗