Challenge
Build a small independently authored classifier for the ENTITY v3.4 Global Passport clean-room campaign without copying, porting or inspecting BTG's v3.4 implementation code.
This is deliberately narrower than implementing ENTITY as a whole.
Allowed target material
Pin the public v3.4.0 release and document exactly which public clean-room/specification files you use. The primary sealed campaign artifact is:
protocol/v3/ENTITY_V3_4_GLOBAL_PASSPORT_CLEANROOM_KIT.min.json
Expected campaign result:
- 24 vectors total;
- 12 VALID;
- 12 INVALID;
- sealed-kit SHA-256:
5869a3fd0ed6cb9f65bf4b20c3bd64933cad82f4aef05c5809e2e05af921f230;
- Global Passport schema SHA-256:
4fbfed9be1b1484bc5d28b8101d1c908b2ccced13e4e99ec896c5b054892ebdd;
- canonical result SHA-256:
ac7504cce70576008cff069607619660a4b9bf0cad43b3f3de81078f1e80d9ba.
Independence boundary
For this attempt to count as independent evidence:
- use a repository controlled by you/your organization;
- do not copy or port BTG's
src/38_Global_Passports/ implementation or the BTG-controlled Rust, TypeScript, C#, Go, Swift or Java baselines;
- choose your own language, architecture, libraries and test strategy;
- document the exact public files consulted;
- publish failures and ambiguities as well as successful results.
If the public material is insufficient to implement a rule without reading BTG implementation code, that is a useful finding. Report the ambiguity rather than consulting the implementation and weakening the clean-room evidence.
Completion levels
A useful result can be any of:
- implementation attempt + specification ambiguity report;
- partial classifier with documented unsupported cases;
- 24/24 classifier convergence with independent CI evidence.
This issue does not by itself require live interoperability, full ENTITY implementation, domain-package deployment or sovereign recovery qualification.
If you reach 24/24 independently, link the repository and CI evidence so the result can be reviewed against ENTITY's public interoperability claim boundaries.
Challenge
Build a small independently authored classifier for the ENTITY v3.4 Global Passport clean-room campaign without copying, porting or inspecting BTG's v3.4 implementation code.
This is deliberately narrower than implementing ENTITY as a whole.
Allowed target material
Pin the public
v3.4.0release and document exactly which public clean-room/specification files you use. The primary sealed campaign artifact is:protocol/v3/ENTITY_V3_4_GLOBAL_PASSPORT_CLEANROOM_KIT.min.jsonExpected campaign result:
5869a3fd0ed6cb9f65bf4b20c3bd64933cad82f4aef05c5809e2e05af921f230;4fbfed9be1b1484bc5d28b8101d1c908b2ccced13e4e99ec896c5b054892ebdd;ac7504cce70576008cff069607619660a4b9bf0cad43b3f3de81078f1e80d9ba.Independence boundary
For this attempt to count as independent evidence:
src/38_Global_Passports/implementation or the BTG-controlled Rust, TypeScript, C#, Go, Swift or Java baselines;If the public material is insufficient to implement a rule without reading BTG implementation code, that is a useful finding. Report the ambiguity rather than consulting the implementation and weakening the clean-room evidence.
Completion levels
A useful result can be any of:
This issue does not by itself require live interoperability, full ENTITY implementation, domain-package deployment or sovereign recovery qualification.
If you reach 24/24 independently, link the repository and CI evidence so the result can be reviewed against ENTITY's public interoperability claim boundaries.