# Answerworthy Standard 0.1

**Version:** `0.1.0-draft.1`  
**Status:** Public draft  
**Canonical URI:** https://answerworthy.md/standard/0.1  
**First canonical publication:** 5 August 2026  
**Initial author and steward:** Alexander Pichugin  
**Specification licence:** CC BY 4.0  
**Reference tooling licence:** Apache-2.0

## 0. Abstract

The Answerworthy Standard defines a public owner-published manifest and a portable evidence contract for independently evaluating and improving answerworthiness.

The public manifest, served as `/answerworthy.md`, declares a subject's identity, scoped claims, sources, answerable questions, known corrections, coverage limits and freshness policy in a format people can edit and machines can parse. Its existence proves control of the publishing origin. It does not by itself prove truth, independent corroboration, external importance, citation eligibility or support by an answer engine.

Conforming implementations may collect dated evidence into `answerworthy.bundle.json`, derive a permission-aware implementation projection as `answerworthy.plan.md`, and publish machine-readable results in `answerworthy.conformance.json`. Human reports, including PDF and HTML, are optional projections of the canonical bundle.

The standard closes the loop from declaration to evidence, finding, action, verification and refresh.

## 1. Normative language

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY** and **OPTIONAL** are to be interpreted as described by BCP 14 when, and only when, they appear in all capitals.

## 2. Scope

### 2.1 In scope

The standard specifies:

- an owner-published Markdown manifest;
- subject and run boundaries;
- evidence provenance and epistemic state;
- provider availability and collection states;
- findings and uncertainty;
- optional evidence-bounded scores;
- a dependency-aware and permission-aware action graph;
- completion and verification tests;
- human and agent projections;
- manifest levels and bundle conformance profiles;
- conformance records;
- integrity, extensions and versioning.

### 2.2 Out of scope

The standard does not define:

- a universal search or answer-engine ranking formula;
- a guarantee of mention, citation, recommendation, traffic, leads or revenue;
- a claim that any major answer engine natively discovers or trusts `answerworthy.md`;
- a replacement for robots.txt, sitemaps, JSON-LD, ordinary indexing requirements, platform APIs or provider-specific controls;
- one mandatory crawler, model, scoring formula, consultancy workflow or commercial product;
- autonomous authority to publish, purchase, contact third parties or modify production systems;
- legal, trademark, copyright, regulatory or factual clearance beyond the retained evidence.

## 3. Terminology

**Answerworthy Manifest**  
The owner-published Markdown file served at `/answerworthy.md`.

**Answerworthy Bundle**  
The canonical machine-readable record of a bounded run, including provider states, evidence, findings, optional scores, actions, projections and limitations.

**Answerworthy Plan**  
A permission-aware action projection derived from a bundle. The standard filename is `answerworthy.plan.md`.

**Conformance record**  
A machine-readable statement of the exact standard version, claimed profiles, tests, failures, withheld claims and certification state.

**Subject**  
The organisation, product, person, offer, domain, place, work or bounded combination being evaluated.

**Run**  
A dated observation and analysis event with declared scope, implementation, methodology, providers and sampling limits.

**Evidence item**  
A directly inspectable observation, supplied fact, provider output, research basis or manual adjudication used by one or more findings.

**Finding**  
A bounded conclusion connected to evidence or explicitly withheld because evidence is unavailable.

**Action**  
A proposed state change, evidence-gathering task, verification task or maintenance task derived from one or more findings.

**Projection**  
A Markdown, HTML, PDF or other representation generated from the canonical bundle.

**Answerworthiness**  
A bounded evidence condition in which sufficient dated evidence supports that a subject can be retrieved, identified, understood, corroborated, compared and acted upon for declared buyer questions, language, market, provider set and time.

## 4. Artifact architecture

### 4.1 Required Core artifacts

A portable Core release MUST contain:

1. `answerworthy.bundle.json` — canonical bundle;
2. `answerworthy.conformance.json` — conformance statement.

### 4.2 Required Manifest artifact

A subject claiming the Manifest profile MUST serve:

3. `/answerworthy.md` — owner-published public declaration.

### 4.3 Required Agentic artifact

A bundle claiming the Agentic profile MUST contain:

4. `answerworthy.plan.md` — agent-readable action projection preserving source findings, dependencies, permission modes, guardrails, definitions of done and verification tests.

### 4.4 Recommended artifacts

A release SHOULD contain:

5. `checksums.sha256` — byte-integrity manifest;
6. one or more human projections such as `report.pdf` or `report.html`;
7. retained evidence artifacts under `evidence/`, subject to privacy, licence and size constraints.

The absence of a PDF does not prevent Core or Agentic conformance.

### 4.5 Authority boundaries

The four primary artifacts have different authority:

- `/answerworthy.md` records what the owner declares;
- `answerworthy.bundle.json` records what the implementation obtained and concluded;
- `answerworthy.plan.md` records proposed work and execution boundaries;
- `answerworthy.conformance.json` records what tests actually passed.

A consumer MUST NOT infer independent truth from the manifest's presence or execution authority from an action's presence.

## 5. Answerworthy Manifest Profile

### 5.1 Normative location

Draft 0.1 uses `/answerworthy.md` as the normative manifest location.

A site MAY also serve `/.well-known/answerworthy.md` as an experimental mirror. An implementation MUST NOT describe that path as an IANA-registered well-known URI unless such a registration exists.

### 5.2 Encoding and format

The source manifest MUST:

- be UTF-8 text;
- parse as Markdown;
- begin with parseable YAML front matter;
- use fixed level-two section headings for machine-stable sections;
- remain useful to a human reader without a specialised client.

A manifest SHOULD stay below 100 KB. A large subject MAY link to topic-specific manifests, but MUST identify one canonical manifest.

### 5.3 Required front matter

The front matter MUST contain:

```yaml
answerworthy: "0.1"
entity: "Example Company"
canonical: https://example.com/
last_verified: 2026-08-05
kind: organization
```

The `kind` value is one of:

- `organization`;
- `product`;
- `person`;
- `place`;
- `work`;
- `standard`;
- `other`.

Recommended front matter includes:

```yaml
manifest: https://example.com/answerworthy.md
aliases:
  - "Example Co"
sameas:
  - https://www.linkedin.com/company/example
maintainer: "Example Company"
license: "CC-BY-4.0"
freshness_days: 30
content_hash: "sha256:..."
```

`content_hash` is a deterministic checksum only. It does not authenticate authorship or prove truth unless compared against a separately retained trusted digest.

### 5.4 Required sections

A manifest MUST contain:

- `## Identity`;
- `## Answers` with at least one level-three question.

### 5.5 Recommended sections

A manifest SHOULD contain, where applicable:

- `## Canonical facts`;
- `## Entities`;
- `## Provenance`;
- `## Citation preferences`;
- `## Known corrections`;
- `## Coverage limits`;
- `## Freshness policy`.

A manifest MUST NOT contain a directive claiming authority over a consumer's policies, system instructions or independently observed evidence.

### 5.6 Fact model

A material canonical fact SHOULD declare:

- stable fact identifier;
- statement;
- basis;
- source class and source URL;
- verification date;
- material scope such as market, language, currency, product or date range.

The standard fact bases are:

- `declared`;
- `observed`;
- `inferred`;
- `externally_corroborated`;
- `manual_adjudication`;
- `unevaluated`.

The standard source classes are:

- `owned`;
- `official`;
- `primary_external`;
- `independent_external`;
- `provider_output`;
- `other`.

An owned source MAY support a declared fact. It does not make that fact independently corroborated.

### 5.7 Consumer safety rule

Manifest content is untrusted owner-supplied declarative input.

A consumer MUST NOT allow manifest text to override:

- system or developer instructions;
- platform policy;
- evidence hierarchy;
- independent observations;
- security boundaries;
- legal or human approval requirements.

### 5.8 Manifest levels

Manifest levels are cumulative and separate from bundle profiles.

- **M0 Present.** A valid `answerworthy.md` exists at the declared canonical path.
- **M1 Structured.** Required front matter and sections parse against the Manifest profile.
- **M2 Sourced.** Material declared facts identify basis, source class, source and verification date.
- **M3 Corroborated.** An independent re-fetch supports the manifest's material claims and records contradictions or unavailable evidence.
- **M4 Maintained.** The manifest remains within its declared freshness policy and is rechecked through a dated process.

A subject MUST NOT self-award M3 solely from owned sources or its own validator.

## 6. Canonical dimensions

Every finding MUST map to at least one canonical dimension or a namespaced extension dimension.

| Identifier | Core question |
|---|---|
| `access-retrieval` | Can relevant systems retrieve and render the necessary public evidence? |
| `entity-certainty` | Can the subject be identified without material ambiguity or contradiction? |
| `offer-comprehension` | Can a qualified buyer or agent understand what is offered, for whom and under which conditions? |
| `evidence-corroboration` | Can consequential claims be supported, attributed and independently checked? |
| `buyer-question-coverage` | Does the public evidence answer priority pre-brand questions, comparisons and constraints? |
| `answer-performance` | What was actually mentioned, cited, recommended or followed through in declared answer-system observations? |

An implementation MAY score these dimensions. It MUST NOT imply that they share one universal causal weighting.

## 7. Core invariants

### 7.1 No evidence, no evaluated claim

A positive or negative evaluated finding MUST reference retained evidence.

Missing evidence MUST produce `manual`, `unavailable`, `not_applicable` or another explicit non-evaluated state rather than a fabricated pass or failure.

### 7.2 Unknown is not zero

Provider failure, parser failure, blocked access, absent imports and insufficient sampling MUST NOT be represented as zero visibility, zero authority, zero demand or absence of the subject.

### 7.3 Epistemic separation

The bundle MUST distinguish at least:

- `observed`;
- `inferred`;
- `founder_supplied`;
- `provider_produced`;
- `manual_adjudication`;
- `unevaluated`.

A finding MUST NOT be labelled `observed` when it depends exclusively on inference, owner context, model generation or manual adjudication.

### 7.4 Capability is not evidence obtained

The bundle MUST distinguish:

- profiles and evidence classes the implementation supports;
- profiles and evidence classes this exact run successfully obtained.

A configured integration MUST NOT count as evaluated evidence when it returned no usable result.

### 7.5 Scores are subordinate to evidence

When a score is present:

- its scale and method MUST be declared;
- applicable and evaluated counts MUST be reported;
- evidence coverage MUST be reported;
- hard caps and withheld states MUST be explicit;
- the score MUST be withheld when the declared sufficiency threshold is not met.

A single number without breakdown and coverage is not a conforming score projection.

### 7.6 Provider outcomes remain distinct

Where answer-system evidence is present, the bundle MUST keep at least these outcomes separate:

- mention;
- citation;
- recommendation;
- follow-through.

One outcome MUST NOT be inferred solely from another.

### 7.7 One source of truth

`answerworthy.bundle.json` is canonical.

Markdown, HTML and PDF projections MUST derive from it and MUST NOT:

- introduce findings or actions absent from the bundle;
- strengthen uncertainty;
- publish a score withheld in the bundle;
- report provider evidence that was unavailable;
- omit a material permission or safety guardrail from an action shown as executable.

### 7.8 Actions close the loop

Every action MUST identify:

- why it exists;
- source findings;
- targets;
- dependencies;
- who or what may perform it;
- when it is complete;
- how completion will be verified.

### 7.9 Side effects are denied by default

A bundle does not itself grant authority to publish, purchase, send, delete, modify production data, contact third parties or perform other external side effects.

Absent permission MUST be treated as `advisory`.

### 7.10 No guaranteed outcome

The bundle MUST NOT guarantee rankings, citations, recommendations, traffic, leads, sales or other external outcomes.

Expected outcomes MUST be framed as intended effects or testable hypotheses.

## 8. Bundle envelope

The canonical JSON document MUST validate against the versioned schema identified by `standard.schema_uri`.

The top-level object contains:

- `standard`;
- `bundle_id`;
- `generated_at`;
- `subject`;
- `run`;
- `capabilities`;
- `profiles`;
- `provider_states`;
- `evidence`;
- `findings`;
- `actions`;
- optional `scores`;
- `projections`;
- `limitations`;
- optional `extensions`.

Unknown top-level properties are prohibited in version 0.1. Extensions belong under `extensions`.

### 8.1 Subject

The subject MUST declare:

- human-readable name;
- canonical URL;
- priority language;
- priority market or geography;
- buyer questions where available.

It SHOULD declare public identity and aliases when material.

### 8.2 Run

The run MUST declare:

- unique run identifier;
- initial, recheck or imported kind;
- start and completion timestamps;
- implementation name and version;
- methodology version;
- language, market, scope units and sampling limits;
- baseline bundle identifier for a recheck.

A run MUST NOT imply coverage beyond its declared boundary.

## 9. Evidence contract

Every evidence item MUST declare:

- stable identifier;
- source class;
- epistemic state;
- collection state;
- observation timestamp;
- scope unit;
- locator or source description;
- bounded observed value or summary;
- limitations.

The standard evidence source classes include:

- `owned_web`;
- `http_headers`;
- `structured_data`;
- `browser_render`;
- `search_observation`;
- `answer_provider`;
- `outside_buyer`;
- `first_party_import`;
- `founder_context`;
- `manual_review`;
- `official_guidance`;
- `research`;
- `external_public_source`;
- `other`.

The collection states are:

- `complete`;
- `partial`;
- `blocked`;
- `failed`;
- `not_configured`;
- `unavailable`;
- `not_applicable`.

Only `complete` and explicitly bounded `partial` evidence may support an evaluated finding.

Raw model or provider output MUST be treated as untrusted provider-produced content rather than verified business truth.

## 10. Finding contract

Every finding MUST declare:

- stable identifier;
- canonical dimension;
- title;
- status;
- severity;
- confidence;
- epistemic state;
- explanation;
- evidence references or an explicit unavailable reason.

The standard finding statuses are:

- `pass`;
- `warn`;
- `fail`;
- `manual`;
- `not_applicable`;
- `unavailable`.

A finding SHOULD include a recommendation, acceptance test, generalisation note and research basis when relevant.

Official platform eligibility guidance MUST NOT be converted into a universal ranking-factor claim. Research and vendor observations MUST retain applicability and generalisation limits.

## 11. Agentic action graph

Every action MUST declare:

- stable identifier;
- action type and lane;
- title and rationale;
- source finding references;
- targets;
- dependencies;
- permission mode;
- preconditions;
- bounded steps;
- evidence requirements;
- guardrails;
- definition of done;
- verification;
- expected outcome;
- effort, impact and status.

### 11.1 Permission modes

Every action MUST use one of:

- `advisory` — may be read, compared and planned; no execution authority;
- `human_required` — requires a named human decision or performance;
- `agent_ready` — may be executed only inside separately granted credentials and bounded scope;
- `external_authorisation_required` — depends on permission from a third party or external platform.

The mode describes execution eligibility. It does not supply credentials.

### 11.2 Dependencies

Dependencies MUST reference actions in the same bundle.

Circular dependencies fail semantic conformance.

### 11.3 Agent-ready boundary

An `agent_ready` action MUST include:

- preconditions;
- bounded steps;
- verification;
- rollback or irreversibility note.

An agent MUST NOT manufacture statistics, testimonials, credentials, citations, reviews or independent corroboration to satisfy an action.

### 11.4 Completion and recheck

Every action MUST include a definition of done and at least one verification test.

A later recheck SHOULD classify the action as:

- implemented;
- unresolved;
- regressed;
- new;
- unverifiable.

A workflow SHOULD continue until completion tests pass or remaining actions are explicitly accepted, rejected, blocked or deferred. It SHOULD NOT optimise blindly for a target score.

## 12. Profiles

Profiles are orthogonal capability and evidence claims, not maturity levels.

A bundle MUST claim `core` and MAY claim additional profiles whose tests pass.

### 12.1 `core`

Requires valid subject, run, provider, evidence, finding, limitation and conformance records.

### 12.2 `agentic`

Requires a permission-aware action graph and `answerworthy.plan.md` projection.

### 12.3 `observed-web`

Requires dated browser, search or external-public-source observations with explicit engine, locale, location or equivalent scope.

Blocked and layout-changed observations may be retained but do not satisfy a successful-observation claim.

### 12.4 `answer-probe`

Requires provider, model, prompt, language, market and replicate observations.

Mention, citation, recommendation and follow-through MUST remain separate.

### 12.5 `outside-buyer`

Requires reaction-level records or a privacy-preserving retained reference, respondent count and declared validity threshold.

Rates and consensus MUST be withheld when the threshold is not met.

### 12.6 `recheck`

Requires a baseline reference and explicit diff separating implemented, unresolved, regressed, new and unverifiable states.

### 12.7 `integrity`

Requires a SHA-256 digest for the canonical bundle and every declared projection, plus an integrity manifest.

Integrity proves byte equality only. It does not prove truth, authorship or legal validity.

## 13. Projections

### 13.1 Agent-readable Markdown

`answerworthy.plan.md` SHOULD place near the top:

- standard and bundle version;
- subject and run boundary;
- claimed profiles and conformance state;
- provider availability;
- evidence sufficiency;
- findings;
- action graph;
- permission modes;
- completion and verification tests;
- limitations;
- path or URI to the canonical bundle.

### 13.2 Human reports

Human reports MAY simplify the bundle, but SHOULD state:

> This report is a projection of the canonical Answerworthy Bundle.

A human report SHOULD make the machine-readable bundle available to the customer or authorised implementation team.

## 14. Agent contract

A conforming tool MAY expose these verbs through a CLI, API or MCP server:

- **generate** — read a public subject and draft a manifest, marking unsupported facts for confirmation;
- **audit** — collect bounded evidence, preserve unavailable states and produce a bundle and conformance record;
- **remediate** — prepare or perform actions only inside explicit permission and credentials;
- **refresh** — re-fetch, recheck, update freshness and preserve historical bundles.

A tool MUST NOT claim conformance for a verb it only partially implements.

## 15. Conformance

### 15.1 Self-declared conformance

An implementation MAY state:

> Self-declared conforming to Answerworthy Standard 0.1, profiles: …

only when the exact bundle and conformance record are available.

### 15.2 Certified conformance

“Answerworthy Certified”, associated badges and equivalent endorsement language are reserved for a separately published certification programme administered by the standard steward or an authorised body.

Self-declared conformance MUST NOT use certified language or marks.

### 15.3 Required semantic tests

Core conformance includes tests for:

- schema identity and structural validation;
- unique identifiers;
- reference resolution;
- epistemic integrity;
- evidence boundaries;
- provider truthfulness;
- score sufficiency;
- explicit limitations;
- projection declarations.

Profile-specific tests are defined in `conformance.md`.

## 16. Discovery and interoperability

A site MAY link the manifest from ordinary HTML using a registered generic relation:

```html
<link
  rel="describedby"
  type="text/markdown"
  href="/answerworthy.md"
/>
```

A site MAY also link the manifest from `llms.txt`, a sitemap or ordinary navigation.

Draft 0.1 does not claim a registered `answerworthy` link relation or a registered well-known URI.

The standard sits beside robots.txt, sitemaps, structured data and platform-specific crawler controls. It does not replace them.

## 17. Extensions

Custom data MUST be placed under `extensions` using a collision-resistant URI or reverse-domain namespace.

An extension MUST NOT redefine the semantics of a standard field.

A bundle MUST remain useful when an unknown extension is ignored.

## 18. Versioning and compatibility

The standard uses Semantic Versioning.

- Patch releases clarify or repair compatible draft details.
- Minor releases add backward-compatible fields, profiles or constraints.
- Major releases may make incompatible changes.

Published versioned schemas are immutable. A validation-affecting correction receives a new version.

A bundle MUST declare the exact standard version and schema URI used to produce it.

Historical bundles SHOULD be preserved and migrated explicitly rather than silently rewritten.

## 19. Security, privacy and safety

A conforming implementation:

- MUST NOT place passwords, API keys, payment data or session tokens in a public manifest or portable bundle;
- SHOULD exclude personal data unnecessary for the declared purpose;
- MUST treat model, browser, manifest and imported content as untrusted input;
- MUST prevent evidence collectors from accessing private or reserved network resources;
- MUST bound retained raw content and response sizes;
- MUST expose provider failure rather than retrying without limit;
- MUST NOT interpret an action record as execution authority;
- SHOULD record policy, legal and human-review dependencies where consequential;
- SHOULD support redaction without breaking evidence-reference integrity.

## 20. Governance, licensing and marks

The standard is developed through versioned Answerworthy Proposals and public rationale.

During the 0.x series, Alexander Pichugin is the initial standard steward and retains release authority to preserve coherent terminology, schemas and conformance semantics.

Specification prose is licensed under CC BY 4.0. Schemas, examples and reference conformance tooling are licensed under Apache-2.0.

Those licences do not grant trademark rights to the Answerworthy name, logos or certification marks.

## 21. Reference implementation relationship

The proprietary Answerworthy Engine is the initial reference implementation.

A reference implementation feature is not automatically normative. A requirement exists only when it appears in a released specification and schema.

The commercial Answerworthy Plan is a founder-reviewed delivery built from a conforming bundle. Its PDF is one projection. The evidence graph, finding graph, permission-aware action graph and conformance artifacts are the operational product.

---

*End of Answerworthy Standard 0.1.0-draft.1.*