# Answerworthy Standard Governance

**Applies to:** Answerworthy Standard 0.x  
**Status:** Public draft  
**Initial steward:** Alexander Pichugin

## 1. Objectives

Governance exists to keep the standard:

- technically coherent;
- evidence-disciplined;
- implementation-neutral;
- useful to agents and humans;
- versioned and testable;
- resistant to marketing-only dilution.

Open contribution does not mean that every proposed field or product convention becomes normative.

## 2. Initial stewardship

During the 0.x series, Alexander Pichugin is the initial standard steward.

The steward is responsible for:

- accepting and rejecting proposals;
- maintaining terminology and canonical identifiers;
- publishing immutable versions;
- protecting compatibility;
- separating reference-implementation behaviour from normative requirements;
- maintaining conformance and trademark policy.

This initial single-steward model is intended to establish a coherent foundation quickly. It may evolve into a technical steering group after independent implementations and recurring external contributors exist.

## 3. Answerworthy Proposals

Material changes use an **Answerworthy Proposal** (`AWP`).

An AWP contains:

- proposal number and title;
- author and status;
- problem statement;
- normative change;
- schema impact;
- conformance impact;
- security and privacy impact;
- migration path;
- alternatives considered;
- reference implementation evidence where available.

Statuses are:

- `draft`;
- `review`;
- `accepted`;
- `rejected`;
- `withdrawn`;
- `implemented`;
- `superseded`.

Editorial corrections that do not change validation or semantics may be merged without an AWP.

## 4. Acceptance criteria

A normative proposal SHOULD demonstrate at least one:

- repeated use in the Answerworthy reference implementation;
- use by an independent implementation or consumer;
- a clear interoperability failure in the current standard;
- a safety, privacy, evidence-integrity or compatibility need.

A proposal MUST NOT be accepted solely because it supports a marketing claim or increases a feature count.

## 5. Release process

Each release has:

- immutable specification text;
- immutable JSON schemas;
- conformance tests;
- example bundles;
- migration notes;
- changelog;
- canonical URI under `answerworthy.md`.

Releases use Semantic Versioning.

Draft releases use a prerelease suffix such as `0.1.0-draft.1`.

A published schema is never edited in place. A validation-affecting correction receives a new version.

## 6. Compatibility

Backward compatibility means an older conforming bundle remains interpretable without silently changing its meaning.

New optional fields may be added in a compatible minor release. New required fields or changed field semantics require a major release unless the affected version is explicitly marked draft and a migration is supplied.

## 7. Reference implementation

The proprietary Answerworthy Engine is the initial reference implementation.

Implementation code, provider adapters, proprietary criteria and commercial workflows do not become normative by existing in the engine. They become normative only through a released standard change.

The reference implementation SHOULD dogfood every draft profile before it becomes stable.

## 8. Conformance authority

Anyone may publish a self-declared conformance result.

The standard steward controls:

- the official conformance suite;
- “Answerworthy Certified” status;
- certification badges;
- official implementation registries.

Certification policy and fees, if any, require a separately published programme.

## 9. Decision transparency

Accepted and rejected AWPs SHOULD retain rationale.

Security-sensitive details MAY be embargoed until remediation is available.

## 10. Conduct

Contributors are expected to critique claims, evidence, schemas and implementations directly and respectfully.

Deliberate misrepresentation of evidence, undisclosed conflicts, fabricated benchmarks and certification impersonation are incompatible with participation.