Clean-Room Implementation
The strongest interoperability question is whether an unrelated engineer can reproduce ENTITY semantics from public protocol material without copying the BTG reference implementation. BTG also publishes six controlled language baselines so portability and cross-language behavior can be reproduced without pretending those repositories are independent validation.
Six BTG-controlled language baselines
These repositories are useful implementation and reproducibility references. They are all controlled by Blackmore Technology Group and therefore do not count as unrelated third-party implementations.
Rust
Native Rust baseline and current v3.4.2 26-vector Global Passport campaign.
TypeScript
TypeScript/Node baseline with the same current campaign target and CI evidence.
What unrelated evidence looks like
An unrelated implementation should control its own repository, architecture, libraries, source code, test strategy and evidence. Reading public specifications, schemas and sealed vectors is expected; importing or translating BTG implementation code defeats the strongest independence claim.
Recommended independent path
- Pin the exact protocol/release target and verify the sealed kit hashes.
- Document every public specification/schema/vector consulted.
- Implement canonical parsing/serialization and required verification rules using your own design.
- Accept every valid vector and reject every invalid vector.
- Publish source, CI, environment and result hashes in a repository outside BTG control.
- If the narrow campaign converges, continue toward bidirectional live interoperability.
- Export sovereign state, recover it independently and verify the same conclusions where the target campaign supports it.
- Publish failures, ambiguities and exclusions as well as passes.
Reproduce a controlled baseline first
If you want a smaller first step before attempting an independent implementation, issue #48 asks you to compile and reproduce the current BTG-controlled Rust v3.4.2 campaign on Linux. That produces useful external reproduction evidence while remaining clearly distinct from an independently authored implementation.
What does not count as independent
BTG's Rust, TypeScript, C#, Go, Swift and Java repositories are controlled reproducibility baselines. Forking or translating one of those implementations does not make the resulting work independent merely because it lives in a different repository.
Implementation freedom
A clean-room implementer may choose a different internal data model, database, cryptographic library, language or architecture. Conformance is about externally defined semantics and results, not matching BTG's internal code structure.
Canonical status
A derivative or independent implementation can execute without BTG infrastructure. To claim canonical ENTITY status under v3.4.2 it must preserve the verified canonical origin/stewardship lineage. Removing or substituting that lineage makes it a derived-from-ENTITY implementation rather than canonical ENTITY.
Useful failure
If the public material is insufficient to reproduce a decision, open a precise issue describing the ambiguity. That is a protocol-quality finding, not a failed contribution. The project explicitly prefers a documented ambiguity or reproducible failure over weakening the clean-room boundary.