# V1 Stable Release Gate

**Status:** live stable-release control for the public V1 preview

**Applies to:** every manifest-listed book and language, the publish-ready
short-form collection, and the public source pages required to support them.

V1 becomes a stable public release only when the release owner records evidence
that every applicable gate below is complete. A successful build is necessary
but is not, by itself, a release decision.

## Release Record

The final release record must identify:

- portfolio version (`V1`);
- the content-derived publication snapshot;
- release date and release owner;
- included books, languages, formats, and short forms;
- completed review matrices and any explicitly accepted residual risks;
- external-feedback register state;
- source-page publication state;
- build and artifact verification results; and
- stable Git tag, normally `v1.0.0`.

The machine-enforced record lives at
`docs/publication/v1-release-record.json`. It is created only for an actual
stable decision and records schema version `1.0.0`, approval status, V1,
release owner and date, the content-derived publication snapshot hash, all
manifest book-language IDs, the three supported language codes, accepted
residual risks, and evidence references for sections 2 through 7 below. A
placeholder file does not satisfy the gate.

The record deliberately does not contain the Git commit that contains the
record itself. That would be self-referential and impossible to satisfy. After
the gate passes on clean Bible and website trees, an annotated release tag and
deployment attestation bind the record and publication snapshot to the exact
commits that were deployed.

If any project is intentionally withheld, record that exception. Do not imply
that an omitted language or format passed the gate.

## 1. Canonical Source And Version Control

- `VERSION` contains `V1`, and `books.json` mirrors that value.
- Every release source is tracked and the working tree used for the release is
  understood.
- Canonical manuscripts, translations, ledgers, and public essays are linked to
  the exact release commits through the release tag and deployment attestation.
- No historical “second edition,” dated snapshot, or descriptive cover phrase
  is being mistaken for a public version.

## 2. Theological And Source Review

- Governing Scripture claims have been checked in their source-language and
  canonical contexts where wording is load-bearing.
- Patristic and historical claims have been checked against suitable primary
  or authoritative sources.
- DDF coverage has been confirmed for derived theological claims; unresolved
  coverage requests are either resolved or kept out of release claims.
- DDF claim IDs, named routes, source/conclusion ledgers, and epistemic labels
  resolve to the release manuscript.
- Material corrections in DDF have been propagated to every affected book,
  language, resource, and short form.

## 3. Domain And Safety Review

- Every applicable track in
  `docs/review/v1-specialist-review-matrix.md` has exact-snapshot evidence and
  recorded dispositions.
- Scientific, psychological, clinical, legal, financial, safeguarding, and
  operational claims have been reviewed by appropriately qualified people
  where those claims carry real-world risk.
- Empirical proposals are not presented as established findings without
  evidence.
- Referral, reporting, abuse-response, crisis, medical, and mental-health
  boundaries are explicit and jurisdictionally qualified where necessary.
- High-risk findings are closed, mitigated, or explicitly accepted by the
  release owner with a written rationale.

## 4. Pastoral And Reader Review

- Each book has been reviewed by the relevant audiences in
  `docs/review/field-testing-guide.md`.
- Feedback is recorded and dispositioned through
  `docs/review/feedback-process.md`.
- No reviewer's participation is represented as endorsement beyond the
  permission they gave.
- Reader testing confirms that critical distinctions, warnings, and action
  steps are understandable without backstage documentation.

## 5. Localization Review

- English, Spanish, and Indonesian editions have each received direct
  language review appropriate to their audience.
- Localized Scripture quotations, reference formats, translation notices,
  theological terms, idioms, examples, and safety language are checked.
- Localized editions preserve governing claims and boundaries while reading as
  native prose rather than mechanical translations.
- Cross-language differences that affect doctrine, fact, or release scope are
  resolved or recorded.

## 6. Rights, Privacy, And Publication Readiness

- Bible-translation notices and other required copyright statements are
  present and match actual use.
- Quotations, images, fonts, cover elements, and third-party material are
  cleared for the intended distribution.
- Reviewer data, testimonies, case material, and identifiable pastoral details
  have documented publication permission or have been removed/anonymized.
- ISBN, imprint, retailer, accessibility, privacy, terms, and jurisdictional
  requirements have been checked for the actual publication channels.
- Public source pages expose the promised traceability without publishing
  confidential research notes or reviewer information.

## 7. Production Verification

- `npm test` passes from the declared Node toolchain.
- `./build_all_books.sh` completes from a clean, reproducible environment.
- Every expected artifact exists and is associated with the release commit.
- PDFs have been visually inspected for covers, contents, typography,
  references, blank pages, overflow, and image quality.
- EPUBs have been opened in representative readers and checked for navigation,
  reflow, metadata, covers, images, footnotes, and Scripture formatting.
- Cover JPGs and retailer-specific outputs meet the intended platform
  specifications.
- Automated checks are supplemented by human review of representative and
  high-risk pages in every language.

## 8. Final Decision

The release owner signs off only after:

1. all blocking findings are closed;
2. every deferred finding has a documented reason and risk owner;
3. the source and feedback records match the release commit;
4. the final artifacts have been rebuilt from that commit; and
5. rollback, correction, and contact paths are documented.

Create the release record, run the gate on the clean candidate, and then create
the stable tag and deployment attestation that identify the exact clean Bible
and website commits. Do not retroactively alter the evidence used for that
decision; later corrections receive their own traceable commits and release
decision.