Governance

Evidence Packs exist to make assurance evidence portable and verifiable. The goal is a format that works the same way regardless of which tools create or consume it.

The specification is developed in the open. Anyone can read it, implement it, and propose changes. No single vendor controls the format or its evolution.

• • Proposals: Changes are proposed via GitHub issues or pull requests in the specification repository.
• • Review: Proposals are discussed publicly. Implementation feedback from independent teams carries significant weight.
• • Decisions: Maintainers merge changes when there's rough consensus and the change improves interoperability or security without breaking existing implementations.
• • Test vectors: Normative changes must include or update test vectors so implementations can verify conformance.

• • Draft: Sections marked "draft" may change based on implementation feedback. Use in production at your own risk.
• • Backward compatibility: Once a version reaches v1.0, minor versions (v1.1, v1.2) will remain backward compatible. A v1.0 validator will accept v1.x packs.
• • Breaking changes: Changes that break existing implementations require a new major version (v2.0). Major versions will include migration guidance and a transition period.
• • Deprecation: Features may be deprecated in minor versions but will not be removed until the next major version.

• • Test suite: The conformance test suite is the arbiter of correctness. If an implementation passes the tests, it conforms to the spec.
• • Reference implementations: The Go SDK serves as a reference implementation. Its behavior is normative where the spec is ambiguous.
• • Independent implementations: The goal is multiple independent implementations. Spec ambiguities discovered during implementation result in spec clarifications and updated test vectors.
• • Test vectors: Published test vectors cover structural validation, digest computation, signature verification, and profile validation.

• • Self-hosted registries: Organizations may host their own profile registries or mirror existing ones. No central registry is required.
• • Offline verification: Once a profile is resolved and its digest recorded in profile_lock, validation can proceed offline. The digest ensures the same profile is used regardless of network availability.
• • Profiles are optional: Core pack validation (structural integrity, digest verification, signature checks) does not require profile resolution. Profiles add semantic validation on top.
• • Namespace conventions: The evidencepack/ namespace is reserved for reference types and profiles. Organizations use their own namespaces for custom definitions.