# Admission from experimental artifacts

The runner never writes to `canon/` or `patterns/`. A model critique is evidence
for a reviewer, not approval to promote. The working 0.1 metadata
contract is in `canon/PatternSchema.md`; apply it at admission and retain hypothesis
maturity wherever evidence is incomplete.

| Experimental representation | Repository representation |
| --- | --- |
| `source/source.md` plus SHA-256 and bibliography | SourceCatalog entry and source-review record |
| Claim C01 scoped by workspace and source | Claim citation: review path + C01 + original locator |
| Candidate P01 scoped by workspace | CandidateCatalog row; reviewed stable FEP ID only upon admission |
| Candidate Definition/Solution sections | PatternSchema prose with reviewed frontmatter |
| Relation proposal between local candidate IDs | Canonical typed relation between stable pattern IDs |
| Generated critique pass/revise/unknown | Input to a named reviewer; not evidence maturity |

For each promotion, write a review under `research/reviews/` with:

- reviewer, date and whether it is a self-review;
- source workspace, digests and source claim locators;
- candidate IDs mapped to existing/new stable FEP IDs, with merge/split/reject reasons;
- checks against the current pattern schema and at least two competing forces;
- known uses and counterexamples, marking missing evidence explicitly;
- relation endpoints, direction and rationale; prerequisites kept distinct;
- evidence maturity, quality constraints and unresolved questions;
- disposition and links to the changed catalog/pattern files and follow-up tasks.

Synthetic fixtures cannot establish known uses or satisfy evidence admission.
Do not infer recurrence from one source. Draft patterns may retain hypothesis
maturity; do not silently raise it because a model gave a favorable critique.
Cross-source patterns should retain all source-specific candidate mappings.

For later bench graph inspection, materialize reviewed candidates as `kind: entity`
artifacts with a Definition section and a preserved canonical ID, and relations as
typed Subject/Predicate/Object artifacts whose endpoints resolve. This graph-export
adapter remains part of FEP-WP-0004; proposal tables are not a graph export.


## Structural screening before editorial review

```bash
python3 scripts/research_admission.py research/bench/infospaces/WORKSPACE
```

Exit 1 means blocked or unreadable input. Exit 0 means only that the candidate
ledger and relation structure pass; admission is always `not_granted` and semantic
review remains required. Save the JSON report with the editorial review, outside
immutable run receipts. It includes hashes of the artifacts screened.

The current prompts request fenced JSON. Screening also accepts one unambiguous
terminal JSON document without fences; it never repairs JSON or extracts a ledger
from prose. Multiple documents and trailing text are rejected.

The current prompts require one candidate JSON ledger with `candidates`, unique
local Pnn IDs, `known_uses` (implementation plus source locator) and `recurrence`
(`unknown` or `supported`). Supported recurrence requires at least two distinct
located implementations. Relations use one JSON array with candidate endpoints;
empty candidate and relation arrays are valid negative findings.

The checker cannot verify whether a citation is true, whether implementations are
independent, or whether prose contradicts the ledger. It does not parse prose known
uses, establish recurrence, validate the complete PatternSchema, or approve semantic
relations. Those remain explicit editorial checks. Existing runs predate this format
and may fail its contract; do not rewrite them to make a check pass.