Requirement inventory and deferred topics

The requirement inventory explains how to interpret v0.1 conformance coverage. It does not replace the prose specification. The prose remains the final normative authority, while conformance/REQUIREMENTS.md documents how role-scoped requirement IDs, fixtures, schemas, and deferred topics fit together.

​

Requirement categories

The inventory separates conformance material into four categories:

1. Role-scoped requirements — stable AV-BIB-* and AV-CLI-* IDs in the specification.
2. Fixture-covered behavior — deterministic vectors or schemas in conformance/fixtures/ and schemas/.
3. Prose-boundary behavior — requirements that need implementation tests, local policy, OpenAPI/schema review, or manual review rather than one offline vector.
4. Deferred behavior — topics intentionally outside the portable v0.1 baseline.

​

Role-scoped anchors

The stable IDs are the main conformance anchors for v0.1:

• AV-BIB-001 through AV-BIB-018 define conforming bibliotheca behavior.
• AV-CLI-001 through AV-CLI-018 define conforming client behavior.

The machine-readable traceability map is conformance/fixtures/conformance-coverage.json. It maps those IDs to fixture families and schemas. This page is a summary only; schemas/conformance-coverage.schema.json and the coverage artifact are authoritative for role, area, coverage type, schema reference, fixture path, and case-level fields. One AV-* ID can cover several lower-level BCP 14 requirements in the prose.

​

Bibliotheca requirement map

AV-BIB-* IDs describe registry-side behavior. Use this map to find the fixture family or contract surface that exercises each requirement.

​

Client requirement map

AV-CLI-* IDs describe client-side behavior. Use this map to scope parser, resolver, installer, trust, capability, and warning tests.

​

Fixture-covered areas

The v0.1 fixture corpus covers readiness-critical surfaces such as manifest parsing, semantic validation, permissions, identity, resolver behavior, external dependency declarations, archive and integrity behavior, release upload, trust metadata, advisories, capabilities, warnings, mappings, and search. See Conformance fixtures for the fixture family list and runner contract.

​

Prose-boundary behavior

Some normative behavior is intentionally not represented by a standalone offline vector. Implementers and reviewers evaluate these through prose review, OpenAPI/schema alignment, implementation tests, or local policy documentation:

• live registry behavior such as deployed service behavior, storage replication, CDN behavior, and operational consistency
• local authorization policy, including token issuance, token revocation, publisher ownership proofs, and resource authorization
• runtime adapter behavior after the portable load boundary
• cryptographic trust roots and live transparency-log policy
• search ranking and catalog ordering beyond the portable pagination shape
• external dependency discovery surfaces beyond declaration-only exact release metadata

These boundaries are not readiness gaps by themselves. They define what a v0.1 conformance claim can and cannot mean.

​

Deferred v0.1 topics

The following topics remain outside the portable v0.1 baseline unless the corresponding decision record is reopened:

• lockfile file format
• registry-priority policy across configured bibliothecas
• universal prerelease-selection policy
• advisory write authority and moderation workflows
• scanner-finding interchange and scanner severity normalization
• common vocabulary for non-mandatory derived judgments
• universal trust-root policy
• component-level advisory targeting
• transitive closure semantics for role = "meta"
• upload profiles beyond the mandatory http-put portable minimum
• AI-specific BOM profile guarantees beyond the generic CycloneDX baseline
• structured deprecation metadata
• broader MCP configuration formats such as YAML
• finer permission granularity beyond the read/write baseline
• future strict, enterprise, or other profiles beyond the v0.1 core

​

Readiness checklist

Before claiming implementation readiness for a draft release:

1. Validate the artifact corpus with npm run validate:artifacts.
2. Validate the Bibliotheca API with npm run lint:openapi.
3. Confirm every role-scoped AV-* requirement has fixture, schema, OpenAPI, or documented prose-boundary coverage.
4. Confirm deferred topics are documented as local policy choices rather than accidental omissions.
5. For release freeze, perform the endpoint-level prose/OpenAPI drift audit in openapi/PROSE-DRIFT-AUDIT.md.