ENTITY is an open-source engineering project stewarded by Blackmore Technology Group Limited. Contributions should be recognized according to the work actually performed, without converting participation into claims of endorsement, employment, independent validation or authorship beyond the contribution itself.
Useful contributions include more than merged production code. ENTITY recognizes, where attributable and appropriate:
- code and tests;
- documentation;
- reproducible bug reports;
- portability findings;
- specification ambiguities;
- counterexamples;
- security findings handled through the appropriate disclosure path;
- benchmark evidence;
- clean-room implementations;
- interoperability evidence;
- issue triage and review;
- architecture/design analysis;
- examples and onboarding improvements.
A reproducible failure can be as valuable as a passing result.
Depending on the contribution, recognition may appear in one or more of:
- Git commit and pull-request history;
- issue/discussion history;
- release notes;
- a release evidence record;
- interoperability status records;
- repository acknowledgements;
- the public External Contribution Ledger;
- a future contributors/maintainers roster if sustained project participation develops.
Recognition should link to public evidence when possible rather than relying on an unsupported attribution statement.
The External Contribution Ledger records attributable work from people or organizations outside BTG control together with the evidence class and claim boundary for each entry.
This lets the project recognize real outside participation without turning an external bug report, portability result or pull request into a stronger claim such as independent protocol validation, interoperability, security audit or endorsement.
When an unrelated engineer or organization produces independent implementation or interoperability evidence, ENTITY will distinguish that work from BTG-controlled engineering.
BTG will not describe an external party's work as independent unless the relationship and implementation conditions actually support that description.
Likewise, participation in an issue, discussion, pull request or test does not imply that the contributor:
- endorses ENTITY generally;
- endorses Blackmore Technology Group Limited;
- accepts every project claim;
- provides a legal, regulatory, audit or certification opinion;
- has independently validated areas they did not test.
BTG-controlled clean-room or cross-language implementations are credited as BTG-controlled reproducibility work. They are not presented as unrelated third-party validation even if different languages, repositories, teams or implementation techniques are used.
Security researchers may choose public attribution after coordinated disclosure when publication is safe. Anonymous or private credit requests should be respected when operationally possible.
Security reports should use the process in SECURITY.md. Do not place exploitable details, private keys, credentials or affected private data into public recognition records.
A contributor may be acknowledged in release notes when their work materially affects that release, for example by:
- authoring a merged change;
- identifying a defect fixed in the release;
- producing a reproducible conformance or portability result referenced by the release;
- contributing a security finding that was remediated;
- producing an external implementation/interoperability result relevant to the release evidence.
Acknowledgement should be factual and scoped. It should not overstate the person's role.
Contributor recognition is not the same as maintainer authority.
If the project later assigns formal maintainer roles, those roles should be documented separately with explicit scopes, review powers, security responsibilities and governance boundaries.
If contributor attribution is inaccurate, incomplete or unwanted, open a documentation issue or contact BTG through an appropriate private channel when privacy or security is involved. Public records such as Git commit authorship remain governed by the underlying Git/GitHub history, but project-authored recognition material can be corrected in a later commit.