Flagship Release Candidate

The flagship-release-candidate-bundle is the review boundary for the repository’s strongest workflow-family evidence. It is not an unqualified release approval. Publication remains blocked whenever ownership, generated governance, Runtime reproducibility, public language, or downstream consequence reports a narrower result.

Candidate Scope

• full outsider-readable family packets: dda, dia, lfq, ptm, targeted
• internal-support-only workflow families: multiplex

An outsider-readable packet means the sources, manifests, outputs, tests, limitations, and review route are available for inspection. It does not mean every family has the same Runtime mode or allowed claim. In particular, the DDA black-box lane remains review-grade bounded because it begins after external search execution.

Evidence Inventory

flowchart LR
    roots["paired public benchmark packages"] --> stability["family_stability_scorecard.json"]
    stability --> rerun["independent rerun dossiers"]
    rerun --> review["external review kits"]
    review --> consequence["requested-versus-observed outcome dossier"]
    consequence --> index["public artifact index + role matrix"]
    index --> decision{"candidate accepted?"}
    decision -->|no| refusal["narrow or refuse release language"]

The bundle must retain:

• primary and companion benchmark manifests for each covered family;
• family_stability_scorecard.json and its perturbation evidence;
• independent rerun dossiers with environment and artifact identity;
• external review kits that do not depend on maintainer narration;
• a requested-versus-observed outcome dossier when follow-up evidence exists;
• the public artifact index and Public Artifact Role Matrix;
• current claim limits, refusals, and the exact release-preflight result.

No artifact can substitute for a different authority layer. A run bundle does not replace benchmark acceptance; a decision brief does not replace grounded evidence; a clean outcome does not retroactively authorize the original recommendation.

Stability And Coexistence

The candidate review requires a stable coexistence map for canonical packages, compatibility distributions, public imports, commands, schemas, and artifacts. Compatibility aliases must either preserve observable parity or carry explicit retirement evidence.

It also requires a stable language-demotion rule set. When the requested family language exceeds black-box, grounding, recommendation, or consequence evidence, the candidate adopts the lower allowed language automatically. A release note cannot override that demotion.

Blocking Review

Open these surfaces in order:

1. Workflow claim limits for requested and allowed language;
2. Core benchmark assets for source, license, acceptance, freshness, and incompleteness;
3. Execution and Black-Box Run Verification for actual run mode and rerun evidence;
4. Decision Support for grounding, challenge, and recommendation stability;
5. Lab Consequence for readiness, burden, refusal, and observed outcomes;
6. Release Narrowing Protocol for evidence-led language demotion;
7. Hostile Review Kit for independent scrutiny;
8. Why This Repository Is Not Ready Yet and What Would Make This Repository Ready for open vetoes and their closure evidence.

Reader Routes

• Open Workflow Families to compare family trust status, run mode, benchmark coverage, and blockers.
• Open Execution to distinguish native, delegated, and imported work.
• Open Decision Support to identify the owner currently limiting the advisory conclusion.

The candidate is publishable only when the tagged source, package ownership, generated governance, benchmark evidence, Runtime lane, consequence chain, and public language agree on the same bounded result.