Agent-Facing Publication Gates
Universal Manifest treats agent-facing surfaces as contracts, not marketing copy.
If a route, descriptor, catalog, or agent-oriented document is easy for an agent to trust, it must be held to stronger publication standards than ordinary prose. This page defines that standard.
What Counts As Agent-Facing
Section titled “What Counts As Agent-Facing”These surfaces are covered by the publication gates:
- landing and agent-entry routes that explicitly route agents
llms.txt- well-known descriptors
- runtime descriptors and OpenAPI
- machine-readable indexes and catalogs
- agent-oriented public docs
- public tool pages when they are described as part of the agent path
Universal No-Publish Rules
Section titled “Universal No-Publish Rules”Do not publish or promote an agent-facing surface if any of these are true:
- it claims a capability that does not exist
- it points to routes or files that do not resolve
- it blurs authority between
universalmanifest.netandmyum.net - it presents a partial or experimental surface as if it were finished
- it omits important status information such as stable versus draft
- it cannot be backed by a real file, real endpoint, real route, or real testable behavior
Required Gate Categories
Section titled “Required Gate Categories”G-A1: Authority clarity
Section titled “G-A1: Authority clarity”The surface must make clear which host owns which behavior and which source is canonical for the task.
G-A2: Completeness
Section titled “G-A2: Completeness”Every published path must be usable end to end. An agent should not be led into a dead end, missing prerequisite, or private internal dependency.
G-A3: Verification
Section titled “G-A3: Verification”Claims must be backed by executable checks, build output, endpoint verification, or browser validation. “We think this exists” is not enough.
G-A4: Freshness
Section titled “G-A4: Freshness”Machine-readable artifacts must expose current status and be regenerated or updated when the underlying route, version, or catalog changes.
G-A5: Status honesty
Section titled “G-A5: Status honesty”Stable, draft, experimental, read-only, and unsupported must be stated explicitly wherever omission would cause an agent to over-claim.
Artifact-Specific Minimums
Section titled “Artifact-Specific Minimums”Discovery files
Section titled “Discovery files”For llms.txt and well-known descriptors:
- every referenced URL must resolve
- the discovery order must match the current public route strategy
- supported and unsupported interaction modes must be explicit
- host ownership must be explicit
Machine-readable catalogs
Section titled “Machine-readable catalogs”For fixture and scenario catalogs:
- catalogs must be generated from real source material, not hand-curated guesses
- counts must match the published items
- each item must point to a real public file or route
- generation date must be present
Runtime contracts
Section titled “Runtime contracts”For resolver descriptors and OpenAPI:
- routes must be live
- contract docs must agree with the runtime behavior
- tests or smoke checks must exist for the surfaced contract
- read-only posture must be explicit if no write path exists
Agent-oriented public docs
Section titled “Agent-oriented public docs”For onboarding and guidance pages:
- they must identify authoritative sources
- they must distinguish normative, supportive, and future-facing material
- they must not instruct agents to use unsupported capabilities
- they must point back to the contract layer for claims that matter
Tool-surface claims
Section titled “Tool-surface claims”For Sandbox, Harness, Workbench, and Resolver UI references:
- the tool must exist and load
- the claim about what the tool demonstrates must be accurate
- tooling must not be presented as proof of unsupported runtime behavior
Required Verification Before Publication
Section titled “Required Verification Before Publication”At minimum, contributors should verify the following:
- Regenerate any discovery or catalog artifacts affected by the change.
- Build the site successfully.
- Run runtime tests or typechecks if resolver contracts changed.
- Browser-check every changed public page or route.
- Confirm referenced machine-readable files are served and readable.
- Check the changelog or status docs before making freshness-sensitive claims.
Publish Or Hold
Section titled “Publish Or Hold”Publish only when:
- the route exists
- the claim is backed
- the authority is clear
- the status is honest
- the verification evidence exists
Hold publication when any one of those is missing. Partial agent-facing surfaces create more risk than unpublished ones because agents will trust them too early.
Why This Is Stricter
Section titled “Why This Is Stricter”Humans can often detect hedging, drift, or ambiguity. Agents often cannot. That means low-quality agent-facing material does not merely confuse; it scales confusion. The only defensible posture is to make these surfaces explicit, narrow, and well verified.