Public-claim routes — qualification

Record status

Record ID

field-guide:public-claim-routes

Parent lifecycle

candidate

Page lane

docs_urls

Lane lifecycle

proposed

Owner

Tilly

Owner role

Not separately recorded

Owner status

Not separately recorded

Qualification result

NOT RUN · held for evidence and human review

Working browser surface: Field guides — documentation — Inspect the guide and persist local checkpoints. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

Qualification status

Result

NOT RUN

Disposition

HELD

Reviewer

Not recorded

Receipt

Not recorded

This page defines proposed acceptance criteria for the docs_urls lane. It does not execute tests, establish compliance, qualify the subject, or authorize an effect.

Outcome definitions

Verified

All stated evidence and acceptance requirements passed for the exact reviewed revision; this still does not authorize deployment or an external effect.

Failed

One or more deterministic acceptance requirements failed with an inspectable reason.

Needs review

Evidence or interpretation is incomplete, conflicting, or awaits an identified human reviewer.

Held

Authority, required evidence, safe execution conditions, or a principal gate is absent.

The current record remains NOT RUN / HELD. These definitions describe candidate outcomes only.

Proposed deterministic acceptance tests

Route-resolution and distinct-content checks apply only to the admitted canonical routes in this record. Held source-proposed extensions are non-resolving proposals and are excluded.

• Every proposed docs route has a unique path, title, audience, search question, and content promise.
• The overview explains scope, ownership, lifecycle, and held effects without claiming deployment or publication.
• The steps page lists the ordered review workflow, including evidence, qualification, approval, and failure handling.
• The forms page specifies implementable fields for claims, evidence, routes, qualification, decisions, and deadlines.
• The examples page contains at least one allowed claim example and one held claim example, each with evidence and decision rationale.
• The qualification page requires an exact allowed instrument slug and records limitations, reviewer, and status.
• Each related-job page explains a distinct handoff and links back to the relevant claim, evidence, route, or approval record.
• A route with duplicate content, keyword-only variation, or doorway intent fails review and is held.
• Missing provenance, source locator, source hash, owner, or reviewer leaves the claim Needs review or Held.
• Prototype app routes are labelled prototype or indexed according to the supplied route state; no route is described as connected production infrastructure.
• No test passes if the content claims provider connection, credential use, database authority, customer indexing, publication, or production effect.
• Accessibility checks include keyboard navigation, visible focus, labels, heading order, readable contrast, and text alternatives for non-text examples.

Negative and held-state tests

• A native surface or named app route may be mistaken for a connected web feature.
• A prototype or indexed route may be described as deployed, public, customer-facing, or production-ready.
• Distinct URLs may become doorway pages if they repeat the same claim with minor keyword changes.
• Evidence may be stale, conflicting, incomplete, or detached from its source locator and revision.
• Educational instrument output may be mistaken for professional advice, certification, or a final public claim.
• The allowed instrument directory includes statuses with errata; qualification must preserve the instrument status and limitations.
• Deadline pressure may cause unsupported claims, skipped review, or accidental external effects.
• Files and capture surfaces may be mistaken for upload, protected storage, or database custody.
• Accessibility failures can make otherwise useful documentation unusable.
• Unreviewed drafts may be sent, exported, indexed, or published without a human receipt.

Qualification claim boundary

Potentially allowed only after the stated evidence

• This guide is a proposal for reviewing and routing public-facing claims.
• The supplied GuthHub and Notebook surfaces have the capabilities and lifecycle states stated in the observed native contract and app-route record.
• Notebook records can preserve canonical IDs, provenance, source locators, source SHA-256, revisions, lifecycle, tags, links, attachments, and record revisions.
• PointGuard is described as a persistent cross-app context surface whose specialist apps remain execution and canonical-record owners.
• The exact verified instrument wcag-contrast-ratio-checker may be referenced for educational contrast checks, subject to qualification notes and limitations.

Still held

• Deployment, publication, customer indexing, provider connection, credential use, database authority, and production effects.
• Any claim that an app route is a connected web feature merely because a native surface or route is named.
• Qualification, compliance certification, professional advice, or guaranteed correctness based only on an instrument result.
• External calendar writes, message sends, exports, uploads, protected storage, or other external side effects.
• Any unsupported live metric, customer outcome, grant result, or website performance claim.
• Final approval of a claim without a named human reviewer and preserved receipt.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• source_record:field-guide:public-claim-routes
• agents/index.html#tilly
• field-guide:public-claim-routes:docs_urls
• Observed native contract: project_and_field_guide_collections
• Observed native contract: deadlines
• Observed native contract: records
• Observed native contract: pointguard
• /app/notebook/field-guides/
• /app/notebook/approvals/
• /app/notebook/search/
• /app/notebook/agent-logs/