Skip to content

[umbrella] Surface the buried projects — DYADT is the worked example, the detector is the deliverable #635

Description

@hyperpolymath

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-that404. 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

  • Mint hyperpolymath/did-you-actually-do-that and move the implementation out of patallm-gallery
  • Reconcile against the authoritative spec. This is the part that is not a file move.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    meta:umbrellaParent issue aggregating child issuesscope:estateAffects many or all repos across the estatetech-debtKnown shortcut, drift, or hygiene owed - includes cleanup

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions