# Public Release Boundary

Status: repository policy for public-safe artifacts and review packets.

## Purpose

CCT Labs needs outside review, rerunnable method artifacts, and credible public
evidence of discipline. That does not require transferring experimental
advantage.

The public release rule is:

```text
Expose auditability, method discipline, and route behavior.
Protect recipe-level information that would let another group reproduce or
commercialize a promising bench lane before CCT Labs has the resources,
partnerships, and review gates to advance it.
```

This policy applies to public docs, public replication packages, review packets,
synthetic capsules, preregistration excerpts, and public-facing examples.

Public-safe means eligible for selection, not automatically published. Public
sites, repositories, packets, and downloadable releases must be built from an
explicit allowlist appropriate to their purpose.

## Eligible For Public Selection

These are candidates for public selection when they are synthetic,
dimensionless, redacted, or otherwise non-recipe-level:

- theorem and verifier logic;
- Reference Stack schemas and manifest validators;
- generic RFH, `Prog_T`, OP2, BT6, OP1, BT7b, and Vector OP4 estimators;
- route labels, decision semantics, and promotion gates;
- public-safe synthetic examples;
- null-control, negative-result, and bench-report templates;
- high-level bench questions and claim classes;
- redacted or synthetic simulation capsules that show route behavior;
- reviewer prompts and packet run commands that do not expose protected lane
  details.

Selected artifacts can establish method depth without requiring access to the
complete working record or protected implementation layer.

## Protected By Default

These stay out of public artifacts unless there is an explicit release decision:

- specific bench materials, recipes, sample preparation, and procurement details;
- optical layouts, RF/EM geometries, and field configurations;
- drive recipes, waveform searches, controller searches, and parameter sweeps;
- protected operating-region values, target coordinates, thresholds, and
  tolerances;
- calibration registers, alignment tolerances, instrument settings, and hardware
  value registers;
- internal notebooks, branch configs, failed-search maps, and raw private run
  histories;
- direct bench-translation instructions for a positive candidate lane.

The protected set includes negative-search information when it would reveal
where the promising route is not, because that can still reduce another group's
search cost.

## Negative Results And Failed Searches

CCT Labs does not automatically publish every failed bench run or failed search
map.

Public-facing failures should usually expose:

- the route decision, such as `no_go`, `narrow`, `baseline_wins`, or `defer`;
- the claim class affected by the result;
- the public-safe reason the branch was killed, narrowed, or rerouted;
- the incumbent or null route that closed the branch when that can be stated
  without recipe-level disclosure;
- redacted negative-result summaries when a public branch changes status.

Protected by default:

- raw failed bench notebooks;
- failed material recipes and sample-preparation details;
- exact failed operating windows, parameter sweeps, and search maps;
- hardware constants, calibration settings, and tolerance records;
- near-miss details that would reveal where the promising route lies.

Failures must be publicly represented when they change the status of a public
claim or public branch. The representation can be a redacted summary, route
label, manifest decision, or negative-result packet. Raw failed-search terrain
stays protected unless there is an explicit release decision.

## Recipe-Level Disclosure Test

Do not release a public artifact if it combines enough of the following to make
a promising bench lane directly reproducible:

1. a positive candidate signal;
2. the concrete material, system, or hardware class;
3. operating-region coordinates or tight parameter windows;
4. drive, readout, geometry, or controller recipe;
5. calibration tolerances or hardware constants;
6. denominator details that imply hidden infrastructure or source settings;
7. bench-translation steps that turn the signal into an executable experiment.

Any one item may be safe in broad, redacted, or synthetic form. The combination
can become the protected asset.

## Allowed Public Pattern

A safe public capsule should usually expose:

- the claim class;
- the abstract task;
- the incumbent and null routes;
- synthetic or dimensionless inputs;
- route labels and decision conditions;
- robustness and failure-map structure without protected coordinates;
- the review gate needed before physical interpretation.

Example public posture:

```text
This capsule shows how a high-response candidate would be scored against
incumbent routes and robustness stresses using synthetic records. It does not
publish the protected operating window, bench layout, drive/search recipe, or
hardware constants for the physical lane.
```

## Review Packet Rule

Review packets should include enough source context for the reviewer to assess
the artifact class. They should not include protected implementation details
unless the packet is explicitly private and the release decision has been made.

When a reviewer needs more detail than the public packet can carry, create a
separate private-review track rather than weakening the public boundary.

## Release Decision

Before publishing or packaging a new artifact, ask:

1. Does this improve public auditability or review quality?
2. Does this reveal a recipe-level combination?
3. Could an incumbent use this to skip CCT Labs' search cost?
4. Can the same review purpose be served with synthetic, dimensionless,
   schema-only, or redacted data?
5. Is the artifact a method-validation object, a branch-narrowing object, a
   bench-facing object, or an actual bench-result object?

If the artifact is useful mainly because it reveals how to run a promising
experiment, keep it protected.

Licensing, patents, collaborations, and funder disclosures are separate
decisions. This file only defines the repository's public release boundary.
