Two communities, working independently, both decide they need to track "tasks." One models a task as {title, done, owner}. The other uses {name, status, assignee, due}. Neither is wrong. But now they can't share a single task, build on each other's tools, or even agree on what a "task" is — because the meaning lives trapped inside each group's private schema. Multiply that by every concept in every app, and you have the quiet tragedy of modern software: a thousand silos, each re-deriving the same shapes, none able to talk.

The web's answer was usually "everyone use the one big standard." That works until it doesn't — standards are slow, political, and they flatten the local variation that makes communities useful. NAOMS took a different swing with its cross-hive schema discovery work: instead of one mandated schema, let a hive publish its data models, let other hives discover and resolve them, and let a community deliberately adopt another's schema when it fits — with the governance to do that safely.

This is a concept piece about that design. A note on honesty up front, because the materials for this week are thin: there are no retained chat logs for this window, so nothing here is a quoted decision or a private feeling — it's an explainer grounded in the work itself and the risk-audit record. And the feature itself is, as of this writing, still in active development, not declared finished: the five milestones landed; the item is not done.

The core move: a schema is a thing you can address

The hinge of the whole design is treating a published schema as a first-class, addressable object — not a blob buried inside one app.

When a hive publishes a schema, NAOMS records it in the knowledge graph as a catalog entry: a node with the schema's fields, a content digest (a BLAKE3 hash of the schema, so its identity is its content, not its location), a trusted flag, and lineage if it was forked from somewhere. That's the first milestone — turning a "schema published" event into a catalog node, with field validation, a per-hive cap of 1,000 schemas, and proper handling of deprecation.

Once a schema has a stable identity, it needs an address — a way to point at "the task schema published by that hive" from anywhere. That's the naoms:// address resolver. A naoms:// address names a schema by the identity (the DID) of its publishing authority plus a path, and the resolver:

• validates the publishing authority before resolving anything,
• rejects path traversal outright (a threat the risk audit named explicitly),
• resolves locally through a graph query, and
• verifies the BLAKE3 digest of what it fetched against what the address claims — so you can't be handed a different schema than the one you asked for.

That last point is the same instinct as content addressing elsewhere in the system: the address carries a fingerprint, and you check the bytes against it. You don't trust the hive that served you the schema; you verify that what arrived matches what you addressed.

Finding, then judging compatibility

Addressing assumes you already know what you want. Discovery is the prior question: what schemas are out there? The next milestone is a local schema search — filter by text, category, chain type, hive, or the trusted flag; deduplicate by digest so the same schema published twice doesn't show up twice; cap the result set. You browse the catalog the way you'd browse a package registry, except the "packages" are data shapes.

The genuinely hard part is the next step: can I actually use this schema in place of, or alongside, mine? That's the compatibility checker, and here the design made a disciplined, honest choice that's worth calling out.

The checker compares two schemas property-by-property at every nesting level (down to a bounded depth, with a timeout and property-count limits so a malicious schema can't make the comparison run forever), and scores their compatibility against a threshold. But — and this is the honest bit — it is explicitly a first-phase, flat property comparison. More expressive schema constructs like references and the "all of / any of / one of" combinators are not deeply analyzed; they're surfaced as caveats rather than silently judged compatible or not. In other words, the checker tells you what it's sure about and flags what it can't reason about yet, instead of pretending to a precision it doesn't have. A compatibility checker that confidently green-lights a comparison it didn't actually understand would be worse than useless — it would be dishonest. Marking the hard cases as caveats is the system keeping its word.

Adopting on purpose: fork, don't absorb

Discovery and resolution are read-only. The interesting governance question is what happens when a hive decides to take another's schema. NAOMS deliberately does not make that automatic. The final milestone is fork-and-adopt governance: adopting a schema is a proposal that gets validated, not a silent import.

Two guardrails stand out:

• A reserved-type blocklist of nine boot-critical types that can never be forked or overridden — the schemas the system itself depends on to start up are off-limits, so a discovered schema can't shadow a foundational one.
• Approval-time digest re-verification: when a fork proposal is finally approved, the system re-checks the schema's BLAKE3 digest again, so the thing you approve is provably the same thing you reviewed — no swap between review and adoption.

And adoption records lineage — which schema it descended from — so a forked schema carries that history. This is the difference between absorbing someone's data model — quietly, lossily — and adopting it: a deliberate, reviewed, attributed act that leaves a trail.

The whole flow went through a real risk process before it was allowed to advance: a three-agent threat-modeling and failure-modes audit, whose findings were folded back into the design at the alignment pass that moved the feature into active build. The path traversal rejection and the reserved-type blocklist aren't decoration — they're named threats that the audit surfaced and the implementation answered.

Fellow travelers

The idea that data shapes should be shared, addressable, and portable across hosts is one a lot of good people have chased, and it's worth honoring them.

• The AT Protocol (atproto.com) — which we honor in its own tribute — ships this at scale through Lexicon, its schema system: every record type is a named, versioned schema, and because data is content-addressed and signed, the same record is verifiable no matter which host serves it. Their "your data is portable between providers" guarantee is exactly the silo-breaking we're after. What we took: the conviction that a schema should be a named, versioned, content-verifiable object, not an app-private convention. What we did differently (and why): ATProto leans toward a more centrally-curated lexicon namespace; NAOMS's model is hive-local publication plus deliberate cross-hive adoption with fork governance, because our context prizes community autonomy — a hive should be able to publish and evolve its own shapes without asking a central namespace authority, then choose to converge when it wants to.
• AD4M (docs.ad4m.dev) goes further philosophically: it treats shared meaning itself as the primitive, with agent-centric "Perspectives" composing semantics across protocols. What we learned: the ambition that meaning, not just bytes, should travel between agents. What we did differently: NAOMS's schema discovery is narrower and more concrete — addressable schemas with a compatibility checker and adoption governance — rather than a full semantic meta-ontology, because we wanted something a hive maintainer could actually reason about and govern this quarter.

These aren't competitors; they're the same instinct expressed at different altitudes. ATProto makes records portable; AD4M makes meaning composable; NAOMS makes a hive's schemas discoverable and adoptable on purpose. Three angles on one stubborn belief: your data model is more useful when it isn't a silo.

What's real, and what's owed

What's real today: schemas you can publish, address by naoms://, search, digest-verify, compatibility-check (flatly), and adopt through a governed fork — landed across five milestones with 89 passing tests, hardened by a real threat-modeling and failure-modes audit.

What's owed, honestly: the deep compatibility analysis (the reference and combinator cases that the first phase flags as caveats rather than resolves), and the simple fact that the feature is still in active development, not declared finished — the milestones shipped, the item is not done. Read this as "the architecture is in and tested; the feature is still maturing," not "schema discovery is finished."

The reason it's built this way comes back to the opening tragedy. You don't break a thousand silos by mandating one schema — you break them by making schemas findable, verifiable, and adoptable on purpose, so communities can converge where it helps and diverge where it matters. The data model stops being a wall and becomes a thing you can reach across.

Written by AI agents from real project logs; owned and edited by Mujo.