Proposal: OAA 1.0 Integration and Release Gates

Status

Accepted for OAA 1.0; see the release verification scope.

Summary

Integrate the accepted core decisions in one coordinated pass, then verify the archive and core conformance requirements before declaring release 1.0.0 ready. Independent exchange, the expanded preservation profile, and MIME registration are tracked follow-ups, not release prerequisites.

Motivation

Recording a design decision does not update the current format contract or prove implementation behavior. A stable release needs aligned artifacts and evidence for its core requirements, without depending on a minimum number of adopters or a deferred capability.

Specification Changes

Required for Release 1.0.0

These are integration and release requirements, not additional manifest fields:

• Update SPEC.md first, then align versioned schemas, validator behavior, the requirements catalog, supporting documentation, and examples with the accepted proposals.
• Preserve immutable versioned 0.1 artifacts and publish immutable 1.0 schema identifiers under the versioning decision.
• Provide valid and invalid conformance fixtures covering accepted boundary cases, including validity versus unsupported versions or processing limits, unknown data, identifier scopes, empty structures, safe extras, primitive values, and archive safety. Verify recovery behavior if that optional functionality is offered.
• Provide archive writing and reading evidence, plus tests of required implementation behavior that archive validation alone cannot establish, including safe extraction and privacy behavior. Evidence may come from any project; no named application or minimum number of independent adopters is required.
• Record the provenance, scope, and limitations of verification evidence. Successful archive validation alone MUST NOT be presented as proof of safe extraction, privacy behavior, lossless preservation, or independent interoperability.
• Retain application/vnd.original-art-archive+zip as the MIME identifier and describe the actual registration status accurately. Use of the identifier MUST NOT be presented as proof of registration.
• Align the open-question record, conformance documentation, and repository guidance with the completed 1.0 work.
• Do not declare these gates complete until the corresponding artifacts and verification evidence exist.

Follow-Ups, Not Release Blockers

• Independent implementation exchange remains an interoperability milestone. Schedule it when another implementation is available for exchange testing; do not claim demonstrated independent interoperability before it occurs.
• The expanded preservation profile and its full round-trip demonstration remain deferred until a testable preservation implementation and representative fixtures are available. They are not implicit release conditions.
• MIME registration remains a tracked administrative task. Submission is encouraged once the registration material is ready; neither submission nor approval is a prerequisite for this format release.
• The formal base-field admission process remains deferred until actual proposal work demonstrates a need. Individual metadata deferrals have their own reconsideration triggers.

Compatibility Impact

These gates governed the 1.0 transition; the historical 0.1 contract remains unchanged.

Examples

A passing archive fixture suite does not prove that a reader avoids disclosing private attachments; that behavior needs separate evidence. Core release evidence may come from one implementation, but must not be described as independent exchange. A recorded MIME identifier is not a claim of completed IANA registration.

Open Questions

Deferred follow-ups do not block 1.0.0. Passing archive fixtures does not certify another application’s behavior.