Trust Boundaries
Each OAN component has limited authority. That limitation is not a weakness; it is the security model. Registrar onboards. Root accepts and proves. CDN distributes. Discovery searches. Trust Indexer projects governance state. Clients verify. Native protocols handle runtime interaction.
When these responsibilities blur, systems become easy to over-trust.
Boundary clarity is also what lets OAN remain extensible. New adapters, ranking models, resource types, and node operators can be added without changing the basic question: which component asserted this fact, and how is it verified?
Component Boundaries
| Component | Can do | Cannot do alone |
|---|---|---|
| Registrar | Validate and submit resource material within scope. | Make a package Root-accepted by itself. |
| Root | Accept package versions and produce proof. | Rank search results or run every resource. |
| CDN | Serve package bytes and artifacts. | Create trust merely by hosting bytes. |
| Discovery | Return signed candidates from verified indexes. | Override Root, lifecycle, or domain scope. |
| Trust Indexer | Project governance events into read state. | Issue Root authorization or publish resources. |
| Client/SDK | Verify evidence and apply policy. | Make unsafe native protocol behavior safe by magic. |
These boundaries help reviewers understand where to look when something fails.
They also help developers avoid oversized components. A Discovery node should not become a hidden Root. A CDN should not become an authority. A website should not become a private-key custodian. A gateway should not silently replace OAN proof with its own undocumented trust signal.
Common Boundary Errors
CDN availability is often mistaken for trust. It is not. A CDN can serve bytes, but the bytes must match Root-accepted hashes.
Discovery ranking is often mistaken for approval. It is not. A score helps relevance, not authorization.
Registrar acceptance is often mistaken for publication. It is not. Root acceptance is the publication trust anchor.
Capability tags are often mistaken for authorized domains. They are not. Tags describe what a resource can do; domains define governed scope.
Endpoint uptime is often mistaken for identity. It is not. A reachable endpoint still needs DID and package binding.
Old visibility is often mistaken for current authority. It is not. A result cached from yesterday may no longer be valid today if the resource or node lifecycle changed.
Extension Boundaries
Future resource types, adapters, semantic rankers, third-party nodes, and enterprise gateways should preserve these limits. A new ranker should not bypass proof. A new adapter should not hide lifecycle. A gateway should not become a secret trust authority unless the model explicitly says so.
OAN can grow only if extensions respect the evidence chain.
This includes semantic extensions. A semantic ranker may create better ordering and explanations, but it should run after admissibility checks and should not return resources outside Discovery scope. Retrieval quality is valuable only when it does not erode trust.
Designing with Boundaries
When adding OAN to a product, ask:
- Which component produced this fact?
- Is this fact evidence or only convenience metadata?
- Is it current?
- Is it scoped?
- Can the client verify it?
- What native protocol control still applies after OAN verification?
These questions prevent accidental trust inflation.
Security review should also ask what happens when a dependency is stale or unavailable. If Trust Indexer is behind, if Discovery has a partial index, if CDN fetch fails, or if lifecycle status is unknown, the safe behavior should be explicit rather than improvised.