LICENSE.md
Specification license for the public EEV documentation and canonical contract. It also clarifies that EEVC remains a certified channel and that certified verification belongs on eevc.link.
Working resources
This page keeps the raw documents close at hand while making their purpose explicit. The goal is that a team does not waste time guessing which document is authoritative, which one drives architecture, and which one mainly supports testing or pedagogy.
eev-format.md
Central public contract specification for EEV: format philosophy, `.eev / .eevz` variants, `ENTRY` and `LIB` structures, canonical rules, plus read-only compatibility notes for already-issued `.eevc` files.
eev-implementation.md
Architecture note: reading, writing, integrity, layer separation, matching, and real runtime behaviour.
eev-recording-guide.md
Recording guide: how to produce a useful, complete, properly annotated fingerprint consistent with the targeted quality tier.
eev-v1-peak-tracks-roadmap.md
Product roadmap for richer `peak_tracks`, the `eco -> standard -> high -> ultra` logic, and stabilization trade-offs.
fallback-matrix.md
Matrix for graceful degradation across browsers, mobile devices, and Android WebView. Very useful for any product targeting real-world runtimes.
qa-regression-checklist.md
Validation checklist before release, algorithm changes, or build publication. Helps avoid silent regressions.
Suggested reading order for a team
- R&D / architecture: start with Format then Implementation
- product engineering: continue with Recording, then the fallback matrix
- QA: review QA checklist + fallback matrix
- documentation / adoption: then use Glossary + For newcomers
Most important triplet
For implementation, the core triplet is simple: Format for the canonical contract, Implementation for software strategy, and the Recording guide for raw-material quality. The other documents frame, test, enrich, or explain.
Checklist before starting development
- decide if you only need `ENTRY` support or also `LIB`
- separate canonical writer rules from tolerant reader rules
- choose how you validate integrity and optional hashes
- prepare test material captured in realistic conditions