Scoring And Release Gate

Scoring and Release Gate

Two separate judgments that must never be collapsed: how good the package is, and whether it may be released.

Iron Law

THE GATE IS BINARY AND CONJUNCTIVE — 19 of 19 or NOT-RELEASABLE. A high score never substitutes for a failed condition.

The score is a quality signal for the people improving the package. The gate is a release decision. A 98 with one unapproved public claim is not ready, and the 98 is irrelevant to that fact.

Scoring

Ten weighted dimensions summing to 100. Full tests and 0/3/5/8/10 anchors: references/scorecard-rubric.md.

Two rules:

• Every deduction cites at least one finding ID. A deduction with no finding is a mood. If the deduction is real, write the finding.
• Every dimension must reach gate.minDimensionPercent of its available points (default 80%). This is a gate condition, not a scoring rule — it exists so a package cannot average well while failing one dimension outright.

Who scores what

Each verification pass scores independently, seeing only its own findings. Do not calibrate toward the other passes or toward an expected number — variance across passes is the signal three passes exist to produce, and averaging it away in advance destroys it.

dossier-scorer issues the final score and is the only issuer of the gate verdict. It sees the final package, the adjudicated findings ledger, and the resolved scope — never the drafting rationale, never the repair rationale, never the author's self-score.

The mechanical / judgment split

Most of the nineteen conditions are checkable by script; the rest need a model to read the package.

This split is load-bearing. A script that evaluated only the mechanical conditions and emitted PASS would make the entire system theater: link-checking and header parsing would certify a package whose security claims were never read. So:

bin/dossier-gate.sh structurally refuses to emit PASS without a dossier-scorer verdict file covering the judgment conditions. Absent that file the result is NOT-READY with reason=no-scorer-verdict, never a pass. tests/bin-scripts.test.sh asserts this specific behaviour.

Per-condition tags and checks: references/release-gate-conditions.md.

The nineteen conditions

G01 score ≥ gate.minScore · G02 every dimension ≥ gate.minDimensionPercent · G03 no unresolved Critical or High finding · G04 no unsupported or unapproved public claim · G05 every required human approval recorded · G06 no secret, credential, personal data, or prohibited disclosure present · G07 no known contradiction that could materially mislead · G08 canonical coverage 100% including justified N/A · G09 every material internal claim has a state and locator · G10 every public claim maps to V/C disclosure-approved evidence · G11 links, paths, and diagram syntax validate · G12 commands and examples executed or visibly marked not executed · G13 planned behaviour not presented as implemented · G14 targets not presented as measured results · G15 policies not presented as implemented controls · G16 unresolved uncertainty and source limitations visible · G17 reviewer-pass independence method disclosed, including model diversity · G18 no hard-category prose-clarity violation exists in the package · G19 no unresolved Critical or High dependency vulnerability lacks a recorded disposition.

Conjunctive. All nineteen, or not releasable.

Verdicts

Never claim perfection. When a condition cannot pass because evidence does not exist, say exactly that and name the evidence needed. A conditionally ready package with three named blockers is a useful deliverable; a release-ready package that quietly skipped a condition is a liability.

Owner-decision items block

An unmade business, legal, or disclosure decision is a real reason a package is not release-ready. needs-owner rows block G05 and G07, and overriding a gate condition is a Tier 3 action requiring explicit human confirmation — recorded with who overrode it and why.

Output Format

## Scorecard — round {n}

| # | Dimension | Weight | Score | Weighted | Min required | Meets min | Justification (finding IDs) |
|---:|---|---:|---:|---:|---:|---|---|

TOTAL={n}/100  MIN_DIMENSION_MET={yes|no}

## Release Gate

| ID | Condition | Type | Result | Evidence |
|---|---|---|---|---|
| G01 | {condition} | mechanical | PASS / FAIL | {value or locator} |

GATE_VERDICT={release-ready|conditionally ready|not ready}
GATE_FAILED_CONDITIONS={G04,G10}
SCORER_VERDICT_PRESENT={yes|no}

### Blockers
| Condition | Why it fails | Exact next action | Owner | Evidence required |
|---|---|---|---|---|

The blocker table is the most-read output of the whole package. Every row must name a specific artifact or decision — "improve evidence coverage" is not an action; "obtain the approved data-retention record for the analytics store" is.

Rationalization Prevention

Integration

Loaded by all three verification passes for independent scoring, and by dossier-scorer, which alone issues the verdict. /dossier:gate runs bin/dossier-gate.sh for the mechanical set and dispatches dossier-scorer for the judgment set. finding-reconciliation supplies the adjudicated ledger. CI reads GATE_VERDICT as an exit condition.

References: references/scorecard-rubric.md, references/release-gate-conditions.md, references/finding-schema.md.