From 86efc31a83f2048b6977dfe7bbd8c89fbf21a941 Mon Sep 17 00:00:00 2001 From: Shawn Blackmore Date: Thu, 24 Sep 2026 10:23:31 -0700 Subject: [PATCH 1/2] Add evidence-backed external contribution ledger --- docs/community/EXTERNAL_CONTRIBUTIONS.md | 55 ++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 docs/community/EXTERNAL_CONTRIBUTIONS.md diff --git a/docs/community/EXTERNAL_CONTRIBUTIONS.md b/docs/community/EXTERNAL_CONTRIBUTIONS.md new file mode 100644 index 0000000..3fba8bb --- /dev/null +++ b/docs/community/EXTERNAL_CONTRIBUTIONS.md @@ -0,0 +1,55 @@ +# ENTITY External Contribution Ledger + +This ledger records attributable work contributed by people or organizations outside Blackmore Technology Group Limited (BTG) control. + +It exists to recognize real external participation **without overstating what the participation proves**. An external bug report, documentation improvement or portability result is an external contribution; it is not automatically an independent implementation, interoperability result, security audit, certification or endorsement. + +## Recorded contributions + +| Date | Contributor | Project / target | Contribution | Public evidence | Evidence class | Claim boundary | +| --- | --- | --- | --- | --- | --- | --- | +| 2026-09-23 to 2026-09-24 | [@kant2002](https://github.com/kant2002) | ENTITY Protocol 1.0 Conformance Kit | Independently attempted the public developer workflow inside a local `.venv`, identified that kit validation recursively treated virtual-environment packages as prohibited implementation files, and supplied reproducible commands/output. The report led to the v1.0.2 developer-mode fix while preserving strict worktree verification for CI/sealed validation. | [Issue #6](https://github.com/blackmore-technology-group/ENTITY-Protocol-1.0-Conformance-Kit/issues/6), [fix PR #7](https://github.com/blackmore-technology-group/ENTITY-Protocol-1.0-Conformance-Kit/pull/7), main merge `905c309d2461ad192514bfd356527119f134739b` | External defect / developer-workflow / portability report | This is real outside participation and a reproduced defect report. It is **not** claimed as independent protocol conformance, independent interoperability, third-party security validation or endorsement of ENTITY. | + +## Why this contribution matters + +The Protocol 1.0 kit is deliberately designed to be exercised by unrelated implementers. The `.venv` report exposed a real developer-workflow defect that BTG-controlled qualification had not surfaced in the same way. + +The correct response was not to dismiss the environment difference or weaken the sealed target. The maintenance fix separated ordinary developer workflow from strict sealed-worktree verification: + +- recognized top-level `.venv` / `venv` environments are ignored in normal developer validation when they are genuine Python virtual environments; +- `--strict-worktree` retains strict verification for CI and sealed qualification; +- protocol semantics, schemas, vectors and pass criteria were not changed to make the test easier. + +That is exactly the kind of external feedback this project wants: a concrete reproduction that improves the public engineering surface. + +## What will be recorded here + +Future entries may include: + +- reproducible external bug reports that materially change the project; +- external portability or environment reproductions; +- merged external pull requests; +- specification ambiguities or counterexamples; +- independently authored benchmarks; +- independently authored clean-room implementations; +- conformance/interoperability results; +- independently authored security-review findings after disclosure requirements are satisfied. + +Each entry should identify the **actual evidence class** and its **claim boundary**. + +## What will not be inferred + +An entry in this ledger does not by itself mean that the contributor: + +- endorses ENTITY or BTG; +- works for or represents BTG; +- independently validated the whole protocol; +- completed live interoperability; +- performed a security audit; +- made a legal, regulatory or certification determination. + +Those stronger milestones require their own evidence and are tracked separately where appropriate, including the [Interoperability Status](../interoperability/STATUS.md) and [Independent Security Review Program](../security/INDEPENDENT_SECURITY_REVIEW_PROGRAM.md). + +## Corrections or attribution preferences + +If a contributor wants an attribution corrected, scoped differently or removed from BTG-authored recognition text, open a documentation issue or use an appropriate private company channel where privacy is involved. Underlying public GitHub issue/commit history remains governed by GitHub and the repositories in which that activity occurred. From 9935c876017bbe09be0964359b1ab6af25dd6a0d Mon Sep 17 00:00:00 2001 From: Shawn Blackmore Date: Thu, 24 Sep 2026 10:23:44 -0700 Subject: [PATCH 2/2] Link contributor policy to public external contribution ledger --- docs/community/CONTRIBUTOR_RECOGNITION.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/community/CONTRIBUTOR_RECOGNITION.md b/docs/community/CONTRIBUTOR_RECOGNITION.md index eda16aa..3a6cd46 100644 --- a/docs/community/CONTRIBUTOR_RECOGNITION.md +++ b/docs/community/CONTRIBUTOR_RECOGNITION.md @@ -32,10 +32,17 @@ Depending on the contribution, recognition may appear in one or more of: - a release evidence record; - interoperability status records; - repository acknowledgements; +- the public [External Contribution Ledger](EXTERNAL_CONTRIBUTIONS.md); - 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. +## External contribution ledger + +The [External Contribution Ledger](EXTERNAL_CONTRIBUTIONS.md) 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. + ## Independent contributors and organizations When an unrelated engineer or organization produces independent implementation or interoperability evidence, ENTITY will distinguish that work from BTG-controlled engineering.