The complaint, in the owner's words
"I'm trying to properly group things in a way that key projects stay on the surface with references, and a lot of them have fallen into repos and been forgotten."
This umbrella is that problem with a worked example, a detector, and the corrections that follow from it.
The worked example: DYADT
The owner's instinct — "that might be dyadt online, but I thought it was there" — was right. It is there. It is just invisible.
A substantial implementation exists at patallm-gallery/did-you-actually-do-that/:
- Elixir brain —
dyadt_brain/lib/dyadt_brain/{claim_registry,verifications,verdict_engine,regression_baseline,attestation,surveillance_supervisor,pattern_learner,verification_manager}.ex, with 11 matching test files
- Rust verification engine — 9 verifiers (
file_existence, content_hash, syntactic, semantic, diff_coherence, dependency, completeness, cross_reference, attestation) plus an SLM ensemble
- Idris2 ABI seam, its own
Justfile, Containerfile, fuzz/, contractiles
ROADMAP.adoc claims v0.1.0 complete
And three independent estate systems already name it as a top-level repo that was never minted:
| System |
Reference |
reposystem/repos.toml:1096 |
url = git@github.com:hyperpolymath/did-you-actually-do-that.git |
gitbot-fleet/scripts/repo-path-overrides.json |
tracked as a repo name |
gitbot-fleet/shared-context/findings/pending/ |
a finding filed against it |
gh repo view hyperpolymath/did-you-actually-do-that → 404. So the estate's own registries believe in a repo that does not exist, which is exactly why it feels like it is there.
Children
1. Extract DYADT and reconcile it against the spec
The spec is complete and lives in standards/did-you-actually-do-that/ — spec/CLAIM-FORMAT.adoc, spec/VERIFICATION-PROTOCOL.adoc, spec/CONSEQUENCE-LEDGER.adoc, plus 9 executable conformance vectors and run-conformance.sh. A reference verifier already runs in CI here (scripts/verify-claims.sh, .github/workflows/dyadt-verify.yml).
⚠️ The orphaned implementation does not reference any of it. Grepping it for conformance|CLAIM-FORMAT|CONSEQUENCE-LEDGER hits only boilerplate. Its "12-layer pipeline / SLM consensus" vocabulary is a different design from the spec's confirmed/refuted/unverifiable + consequence-ledger model. It diverges rather than implements.
This is the substance of #462 — retarget that issue rather than starting from zero. #462's contract clause is the binding constraint: "The spec is authoritative. The verifier MUST NOT relax the confirmed/refuted/unverifiable semantics… Verdicts MUST be re-derived from primary evidence, never read back from the agent's evidence field."
2. The second dyadt
developer-ecosystem/idris2-ecosystem/dyadt/ — an Idris2 library (src/Dyadt/{Claim,Evidence,Verdict,Verifier,Combinators}.idr) with integrations to cno and echidna. Its .ipkg declares homepage = github.com/hyperpolymath/idris2-dyadt, which also 404s.
Decide: fold into child 1, or mint separately.
3. Build the detector — this is the generalisable part
DYADT was invisible because it lived inside an unrelated repo. That is a detectable shape, not a one-off.
Add a hypatia rule for "RSR-shaped project nested inside an unrelated repo" — a sibling of the existing hypatia-rules/implementation-inside-canon.a2ml. Signal: a subdirectory carrying its own Justfile + .machine_readable/ + ROADMAP.adoc + Containerfile while the parent repo's identity is something else.
Then run it estate-wide. DYADT is one instance; the count is unknown and that is the point.
Corollary check: cross-reference reposystem/repos.toml against gh repo list and report every entry naming a repo that does not exist. The registry believing in phantom repos is the same failure seen from the other side.
4. estate-audits is not a repo — amend #495
Owner ruling 2026-08-25: an audit sitting inside one of the repo directories is in the wrong place; audits belong in the appropriate directory in developer/ above the repo trees, i.e. developer/dev-notes/.
Do not create hyperpolymath/estate-audits. #495's body has been corrected.
5. verisimdb-data stays — correction to the record
The working assumption was that this was experimental residue kept aside from canonical verisim, and no longer relevant. It is load-bearing and live.
| Evidence |
|
| last push |
2026-08-25T06:37Z |
| last commit |
scan: estate rescan (run 32810961229) (#92) — automated |
| consumers |
20+ hypatia modules incl. merge-orchestrate.yml, estate-rescan.yml, verisim_connector.ex, fleet_dispatcher.ex, dispatch_manifest.ex, pattern_registry.ex, outcome_tracker.ex, cross_repo_learning.ex |
| status |
one of the four repos in the base ruleset set |
It is the estate's canonical flat-file scan store, and hyperpolymath/hypatia#721 now points the merge brain at it. Do not retire. The only legitimate question #495 can ask is whether PORT-REGISTRY belongs inside it.
6. a2ml — destination corrected
Owner ruling: the a2ml product goes to the existing a2ml-ecosystem (public, pushed 2026-08-24), not a new hyperpolymath/a2ml (which does not exist). The specification stays in standards, including the .scm variant.
#490 retargeted accordingly.
Horizon: the DYADT implementation was assessed by file and test-file presence plus README/ROADMAP claims — I did not run its test suite or verify the 12 layers work. The divergence claim is based on grepping its tree for the spec's vocabulary and finding only boilerplate hits. Repo existence throughout was checked with gh repo view under a token with private visibility, so a 404 means genuinely absent rather than permission-masked.
The complaint, in the owner's words
This umbrella is that problem with a worked example, a detector, and the corrections that follow from it.
The worked example: DYADT
The owner's instinct — "that might be dyadt online, but I thought it was there" — was right. It is there. It is just invisible.
A substantial implementation exists at
patallm-gallery/did-you-actually-do-that/:dyadt_brain/lib/dyadt_brain/{claim_registry,verifications,verdict_engine,regression_baseline,attestation,surveillance_supervisor,pattern_learner,verification_manager}.ex, with 11 matching test filesfile_existence,content_hash,syntactic,semantic,diff_coherence,dependency,completeness,cross_reference,attestation) plus an SLM ensembleJustfile,Containerfile,fuzz/, contractilesROADMAP.adocclaims v0.1.0 completeAnd three independent estate systems already name it as a top-level repo that was never minted:
reposystem/repos.toml:1096url = git@github.com:hyperpolymath/did-you-actually-do-that.gitgitbot-fleet/scripts/repo-path-overrides.jsongitbot-fleet/shared-context/findings/pending/gh repo view hyperpolymath/did-you-actually-do-that→ 404. So the estate's own registries believe in a repo that does not exist, which is exactly why it feels like it is there.Children
1. Extract DYADT and reconcile it against the spec
hyperpolymath/did-you-actually-do-thatand move the implementation out ofpatallm-galleryThe spec is complete and lives in
standards/did-you-actually-do-that/—spec/CLAIM-FORMAT.adoc,spec/VERIFICATION-PROTOCOL.adoc,spec/CONSEQUENCE-LEDGER.adoc, plus 9 executable conformance vectors andrun-conformance.sh. A reference verifier already runs in CI here (scripts/verify-claims.sh,.github/workflows/dyadt-verify.yml).conformance|CLAIM-FORMAT|CONSEQUENCE-LEDGERhits only boilerplate. Its "12-layer pipeline / SLM consensus" vocabulary is a different design from the spec'sconfirmed/refuted/unverifiable+ consequence-ledger model. It diverges rather than implements.This is the substance of #462 — retarget that issue rather than starting from zero. #462's contract clause is the binding constraint: "The spec is authoritative. The verifier MUST NOT relax the confirmed/refuted/unverifiable semantics… Verdicts MUST be re-derived from primary evidence, never read back from the agent's evidence field."
2. The second dyadt
developer-ecosystem/idris2-ecosystem/dyadt/— an Idris2 library (src/Dyadt/{Claim,Evidence,Verdict,Verifier,Combinators}.idr) with integrations tocnoandechidna. Its.ipkgdeclareshomepage = github.com/hyperpolymath/idris2-dyadt, which also 404s.Decide: fold into child 1, or mint separately.
3. Build the detector — this is the generalisable part
DYADT was invisible because it lived inside an unrelated repo. That is a detectable shape, not a one-off.
Add a hypatia rule for "RSR-shaped project nested inside an unrelated repo" — a sibling of the existing
hypatia-rules/implementation-inside-canon.a2ml. Signal: a subdirectory carrying its ownJustfile+.machine_readable/+ROADMAP.adoc+Containerfilewhile the parent repo's identity is something else.Then run it estate-wide. DYADT is one instance; the count is unknown and that is the point.
Corollary check: cross-reference
reposystem/repos.tomlagainstgh repo listand report every entry naming a repo that does not exist. The registry believing in phantom repos is the same failure seen from the other side.4.
estate-auditsis not a repo — amend #495Owner ruling 2026-08-25: an audit sitting inside one of the repo directories is in the wrong place; audits belong in the appropriate directory in
developer/above the repo trees, i.e.developer/dev-notes/.Do not create
hyperpolymath/estate-audits. #495's body has been corrected.5.
verisimdb-datastays — correction to the recordThe working assumption was that this was experimental residue kept aside from canonical verisim, and no longer relevant. It is load-bearing and live.
scan: estate rescan (run 32810961229) (#92)— automatedmerge-orchestrate.yml,estate-rescan.yml,verisim_connector.ex,fleet_dispatcher.ex,dispatch_manifest.ex,pattern_registry.ex,outcome_tracker.ex,cross_repo_learning.exIt is the estate's canonical flat-file scan store, and hyperpolymath/hypatia#721 now points the merge brain at it. Do not retire. The only legitimate question #495 can ask is whether
PORT-REGISTRYbelongs inside it.6.
a2ml— destination correctedOwner ruling: the a2ml product goes to the existing
a2ml-ecosystem(public, pushed 2026-08-24), not a newhyperpolymath/a2ml(which does not exist). The specification stays instandards, including the.scmvariant.#490 retargeted accordingly.
Horizon: the DYADT implementation was assessed by file and test-file presence plus README/ROADMAP claims — I did not run its test suite or verify the 12 layers work. The divergence claim is based on grepping its tree for the spec's vocabulary and finding only boilerplate hits. Repo existence throughout was checked with
gh repo viewunder a token with private visibility, so a 404 means genuinely absent rather than permission-masked.