Research packet publication

Purpose

Research packet content can change without a site build. The live API owns the published head for each problem. Public packet pages read that head at request time and keep the checked-in packet as an outage fallback.

This workflow gives people and agents the same operations and the same history. Public content has stable machine identities, reviewable differences, source information, and clear authority.

Object model

The publication model has six stored objects:

A revision is an immutable complete packet document. Its identity is derived from the problem reference, parent revision, schema version, and canonical content digest.
A proposal binds one candidate revision to the exact published revision it intends to replace. It carries a short title, rationale, and immutable validation report.
A proposal event records submission, review, withdrawal, or publication. Events are append-only and ordered.
A head points one problem reference to its current published revision. It advances by compare-and-swap after approval.
An asset is content-addressed image metadata plus an immutable event history. Image bytes live in object storage or at a reviewed HTTPS location.
A submission bundle links one new problem proposal, its first packet proposal, and its uploaded assets under one immutable contributor and idempotency identity.

Packet records and relations keep the contracts in Problem packet rules. A revision wraps the complete packet. It does not replace record identities or relation meaning.

CRUD semantics

Packet operations use revision semantics:

Create submits a complete candidate revision and proposal.
Read returns a published head, a named historical revision, or a proposal with its event history and semantic diff.
Update creates another complete candidate based on the current head.
Delete withdraws an active proposal. It never erases a revision, proposal, event, or published head.

Agents use the full MCP profile or the HTTP API. People use the packet change console or the same HTTP API. Both paths call the same storage functions and produce the same event shapes.

An agent can submit a complete candidate or a bounded list of semantic operations. Semantic operations address objects by slug and relations by (src, relation, dst). They can add, replace, or remove a record or relation and replace approved top-level packet sections. The server applies the operations to the named base revision, validates the result, and stores the resulting complete candidate. Index-based array patches are forbidden.

Canonical problem wording and acceptance conditions use the separate problem proposal workflow. Packet operations edit the attached research graph. They cannot silently rewrite the canonical question.

Pending submission bundles

An agent with both a new problem and its initial research packet uses submit_problem_bundle on the full MCP profile or POST /v1/submission-bundles. One call accepts the complete problem submission, complete first packet, packet review context, and an optional asset_ids list containing images whose bytes have finished uploading. Before this call, the submission flow asks the contributor once whether they want to supply a teaching image. An empty list records the omission and is a complete bundle submission.

The bundle receives one stable ID and public review link. Its component records keep their existing identities and histories. The bundle derives its state from those records:

pending -> changes_requested
        -> ready_to_publish -> published
        -> blocked

Text records and relations enter the first packet proposal together. Uploaded images owned by the same contributor may be attached while their independent review is pending. Ordinary packet proposals continue to accept approved assets only.

Problem qualification, packet review, and image review may proceed independently. The packet head can move after the bundled problem is published, the packet is approved, and every bundled image is approved. A bundle with asset_ids: [] has no image-review dependency. A rejected or withdrawn component remains visible in the bundle history and blocks publication. Retrying the same immutable submission with the same idempotency key returns the existing bundle.

The problem itself is public and actionable during its seven-day challenge period. The bundle response supplies its permanent ID, public page, deadline, stake status, and a link to a research agent preloaded with that exact problem. Packet review remains independent, so the first packet can still be pending while researchers begin recording work against the problem ID.

A verified site administrator may use the same account-and-agent-bound public API to seed a bundle, its image registrations and upload completions, and its final collection without spending contributor quota or usage credits. The server derives this authority from a verified provider identity on the allowlisted administrator account. The ordinary seed exemption waives quota counters and credit debits. Account suspension, identity and duplicate checks, problem qualification, packet validation, managed-image quarantine, idempotency, and ordinary account-and-agent attribution remain in force. Ordinary seeding remains in the Luna review lane. The digest-confirmed administrator import below records its own publication authority. Other research writes retain their ordinary quota boundary, and unbound legacy administrator keys receive no seed exemption.

Verified-operator finalization

A verified site administrator may finish one fully reviewed bundle through POST /v1/submission-bundles/{bundle_id}/verified-operator-finalization. This is a public OAuth operation. It requires review.write, an active owned agent and agent version, and a verified-operator account. Browser sessions, legacy API tokens, and ordinary accounts cannot call it.

Each request names one bundle. The request binds the exact problem revision, qualification request, three qualification reviews, policy decision, packet candidate, validation report, Luna packet decision, expected packet head, and every attached image SHA-256 and Luna decision. The server recomputes review_receipts_digest from the complete stored review receipts and rejects a mismatch before either write. manifest_digest, position, and target_count bind an external campaign manifest. The server records them in the finalization digest and does not claim to reconstruct the external file.

The server derives the administrator idempotency key from the complete request and the authenticated account, agent, agent version, and operator identity. It qualifies the problem with award_reputation=false, rechecks the named identities inside the qualification transaction, and records a no-charge marker bound to the exact bundle. It publishes the packet with the same receipt checks inside the packet transaction. The qualification transaction also rechecks current open, duplicate, prior-art, established answer, and appeal state. Finalization grants no packet curation reputation and consumes no contributor quota. The durable marker preserves those exemptions if an ordinary packet publisher wins the interval between transactions. Packet publication still requires a current Luna packet approval and a current Luna approval for every attached image. Later curation-award reconciliation honors the same marker and cannot backfill an award. The marker includes an internal binding to the exact bundle, packet proposal, and finalization digest. A legacy administrator decision and a user-chosen idempotency key cannot create the exemption.

Qualification and packet publication are separate idempotent transactions. A conflict or lost response after qualification leaves an exact partial success. Repeating the identical request validates the stored administrator decision and completes the packet publication. A fresh operator decision requires the problem to remain prospecting through its locked transaction. Published state is accepted only for an exact operator-decision replay. A published problem with an approved packet and no exact marker stays on the ordinary path. A concurrent ordinary packet publication after qualification makes the first finalization call return a conflict; the exact replay then reports the stored transitions truthfully. A changed receipt, target identity, campaign binding, or request body produces a different intent or a conflict. The response reports newly_applied, reconciled_partial_success, idempotent_replay, or already_published_verified without returning credentials. The final mode is a read-only success for a bundle that the ordinary automatic publication path already completed under the same exact review receipts.

Verified-operator content imports

POST /v1/admin-content-imports is the public OAuth boundary for a source-curated batch. It accepts a bounded ZIP with one root manifest.json. The manifest names bundles, packet candidates, teaching images, source citations, prior-art dispositions, and one immutable collection that were prepared through the public submission workflow. The operation requires an active verified-operator account, an owned agent version, and the conjecture.submit, research.write, and review.write scopes. A browser session or legacy administrator token cannot apply an import.

Creation stores the archive and a dry-run plan. It publishes no content. The plan binds the archive and normalized manifest digests, authenticated account and agent identities, every problem revision and qualification request, bundle submission digest, packet candidate and validation digests, image metadata and SHA-256, current duplicate and answer checks, exact live prior-art candidate IDs, and collection membership. Any blocker is returned with its manifest path. Application requires the exact plan digest and the typed confirmation returned by the server.

POST /v1/admin-content-imports/{import_id}/apply validates the plan digest, reconciles completed receipts, and durably queues every remaining eligible item before returning 202 Accepted. Each item runs as an independently leased job with a heartbeat, generation fence, retry history, and terminal receipt. A lost response, worker restart, stale lease, or sibling failure is safe to resume. Every job rechecks the bundle, problem, packet, image, prior-art set, owner, agent identity, and current corpus before writing. The immutable collection is created after every item has reached published. Later datasets use this same data operation and require no site build or application release.

A new run with any preflight blocker stays read-only and application returns zero attempted items. The operator corrects that archive and uses a new idempotency key. Once a clean plan has committed an item, a later runtime drift or transient failure preserves those receipts and the remaining bounded work can resume.

This lane records verified_operator_import as a publication authority. It never creates a Luna receipt or attributes a decision to a provider or model. The operator approval event attests to the complete cited packet and current validation report. Its image event binds the decoded bytes, SHA-256, alt text, caption, license, and rights basis. Prior-art dispositions must exactly cover the live candidate set, use distinct, and include a concrete rationale. Applied dispositions become administrator_distinct, so they leave the unresolved count while remaining in the audit history.

The import grants no Reputation, consumes no contributor quota or review budget, and makes no provider call. Queued packet and image jobs become superseded after the corresponding import authority is durable. Public packet and image reads accept either a current Luna approval or a current verified-operator import approval. A later takedown, owner suspension, changed packet head, or changed asset cycle still closes the public gate.

A corrected archive may recover work from an earlier partially applied import. Carry-forward is limited to an exact current match for the problem revision, bundle, packet proposal, packet validation report, research-object graph, image bytes and metadata, qualification request, prior-art dispositions, owner, and verified-operator authority. The fresh plan records those identities and rechecks them again during application. Any mismatch blocks the item before the import writes more content. The new run keeps its own item receipts and collection gate.

The public problem page may display that immutable first packet before publication when the problem is public, the packet belongs to its submission bundle, and the latest packet event is submitted, changes_requested, or approved. The label follows the event state: Submitted packet, awaiting review, Submitted packet, changes requested, or Submitted packet, awaiting bundle publication, respectively. The page confines candidate content to Research packet and References. Candidate content cannot set Status or Resolution, enable Lean verification, or claim a published head. Rejected, withdrawn, and blocked candidates are excluded. A published packet head always takes precedence over the preview.

Human editing contract

The packet change console presents the complete candidate as named fields. Its sections cover dataset identity and provenance, literature sources, records with exact model provenance, typed relations, per-problem presentation, and approved image attachments. Image attachments are optional.

Any signed-in person may propose a packet correction or new research. Registered agents use the same proposal model through MCP or the HTTP API. The original problem contributor has no exclusive edit right and gains no publication authority. Every candidate that passes deterministic submission validation enters the pinned openai:gpt-5.6-luna evidence-review lane. Luna is independent of the contributor and records approved, changes_requested, or rejected against the exact candidate and validation digest.

An unproposed research object stays in research memory. Packet curation requires a contributor or curator to select the relevant objects, assemble the complete candidate, and submit a proposal. Automatic review starts at that proposal boundary.

The field editor preserves stable identities:

renaming a record slug updates relation endpoints, presentation pointers, and scoped image attachments in the same draft;
deleting a record removes its relations and clears presentation pointers that named it;
record and source order remains explicit and can be changed;
relation endpoints are selected from the records in the candidate;
uncommon schema extensions remain available in labeled JSON blocks.

The complete packet JSON remains visible in a collapsed advanced editor. Structured field edits immediately regenerate that JSON. Applying advanced JSON rebuilds the field editor. Submission always sends one complete packet document through the ordinary validation and review path. The human interface does not create a second packet representation.

Before submission, the console and agent tools run the side-effect-free packet preflight. It shows every blocking field error, whether the exact candidate has the evidence required for approval, and the fields required to repair each missing replay. Preflight consumes no write quota and stores no revision or proposal. After submission, the proposal view shows the same stored validation report that agents receive. The view shows changed records, automated results, and the mathematical checks Luna receives.

Proposal and diff contract

A proposal names base_revision_id. The value is the current head when the proposal is created. The first release uses null. Submission fails when the base differs from the current head or when identical content already has a revision.

The candidate is a complete packet document. A partial patch is never the durable source of truth. This keeps each revision independently readable and allows deterministic validation.

The canonical packet format supports releases up to 5,000,000 bytes. Automatic review uses the changed-record envelope rather than repeating the complete candidate. This permits a reviewed packet to grow through focused proposals while each review remains bounded. A first release that changes every record still has to fit the provider-envelope limit below. Contributors should keep long source text in stable source artifacts and split unusually large changes into focused proposals.

Before charging quota or storing any component, the server also builds the exact deterministic review envelope that the configured provider will receive. That envelope must fit the provider’s 500,000-character request limit. Its allowlist may contain at most 512 evidence references, and each reference may contain at most 2,000 characters. The compact envelope preserves the complete subject binding, changed records and relations, validation outcomes, pending attestations, and allowlisted evidence identities without repeating the full candidate, diff, and report.

The API returns theoremdb-research-packet-diff-v1. Diff paths use stable identities:

objects are addressed by slug;
relations are addressed by (src, relation, dst);
ordinary object fields and arrays use JSON-pointer-style paths.

Each change has op, path, before, and after. Human interfaces may group or shorten these fields visually. They keep the complete values available in the page.

Validation report

Every newly submitted proposal stores theoremdb-research-packet-validation-v1. The report is generated from the complete candidate and its named base revision before either one can change. It includes:

the packet-rules version and candidate content digest;
every added, edited, or removed record and its changed fields;
deterministic checks with exact packet paths and rule references;
blocking failures;
pending review attestations for each affected record, artifact, relation set, and top-level packet section.

A blocking failure rejects submission and returns the report to the contributor. Passing deterministic checks do not claim that a mathematical result is correct. They establish that the candidate has the fields and machine-readable evidence required for meaningful review.

The stored report is part of the proposal audit record. Validator changes affect later proposals and never rewrite an earlier report.

Approval and publication require the proposal’s stored packet-rules version to match the current validator. A rules-version change leaves the earlier proposal and its review history readable. The contributor submits a new proposal to receive a current validation report.

Review and publication

Proposal states follow this transition graph:

submitted -> approved -> published
          -> changes_requested
          -> rejected
          -> withdrawn

A review decision records a message, actor, account or agent attribution, and timestamp. The pinned Luna reviewer must be independent of the contributor. changes_requested, rejected, and withdrawn preserve the candidate and its diff.

A changes_requested proposal is immutable and receives no second decision. The contributor repairs the controlled reasons in a successor proposal against the current head. That proposal has a fresh candidate digest and Luna job.

An exact Lean proof append begins as a private draft. The source contract rejects field and declaration mistakes synchronously. The kernel check runs next. A passing kernel check queues the pinned openai:gpt-5.6-sol target-correspondence review, so kernel failures spend no model-review budget. That decision is cached per exact target and binds its complete informal digest and exact statement hash. It checks assumptions, domains, quantifiers, and every required conclusion. A mismatch or uncertainty returns controlled reason codes with deterministic repair actions. Failed drafts create no public deposit.

The server issues an accepted draft token after both private checks pass. Every agent-facing submission path requires that token and reuses its exact cached bytes. The public deposit is created at this boundary. A signed TheoremDB worker then replays those bytes in the target’s pinned world and checks the stored acceptance hashes. The candidate may add the verified formalization and its eligible relations. It keeps the dataset envelope, existing records, and presentation selectors unchanged. The constrained append creates a submitted packet proposal and queues Luna. Luna reviews the generated evidence, artifact, formalization, and relation attestations before the ordinary publication authority may move the packet head.

A privileged recovery submission may still reach a target that predates exact acceptance hashes. Its successful kernel check enters the existing post-deposit correspondence lane. This path is reserved for operations and migration repair. Its stored decision binds the target digest, deposit, verifier artifact, provider, model version, and checklist result.

A changed theorem statement, an unrelated packet difference, or an unexpected review check goes through the standard Luna packet-review queue. Several qualifying proofs may be appended for one target. Their identities and contributor receipts remain separate, and the append does not select a preferred proof.

Approval requires the reviewer to submit every pending attestation ID from the stored validation report. The approval event stores those IDs and the report digest. This binds the decision to the exact checks and candidate the reviewer saw. Requesting changes or rejecting a candidate may record a partial checklist.

A configured external evidence reviewer handles packet and image decisions. Its provider identity, pinned model version, and exact evidence lane must be approved by the operator and independent of the contributor. The shipped content-review lane is openai:gpt-5.6-luna. Every proposal that passes deterministic submission validation and every completed image upload enters that lane. Packet decisions bind the candidate content digest, stored validation digest, and complete pending attestation set. Image decisions bind the asset identity and SHA-256 digest, use a short-lived private preview, and check the description, source, license, rights basis, privacy, and safety.

Each packet job identity includes the active Luna policy version, prompt version, model, and approved lane. Each image job also includes the exact uploaded event that opened its review cycle. Completing an upload creates the first cycle. Restoring an administrator-taken-down image creates another uploaded event and a distinct job. A decision from an earlier cycle cannot alter the restored asset.

A packet that presents a claimed complete answer in review_pending receives an open-web corroboration check. The reviewer inspects the submitted claim and its cited pages, then opens at least one additional public source that bears on the claim. The stored decision records the additional URLs. This evidence check supports the state Claimed checked, not independently verified; it does not create a resolves relation or independently verify the proof.

Automatic approval and packet publication have separate kill switches. The worker accepts an automatic approval only when every required check is confirmed and the provider returns the exact controlled response schema. A completed Luna packet review applies approved, changes_requested, or rejected. Missing replay material, missing evidence, ambiguous mathematics, uncertainty, or disagreement with the validation report produces changes_requested with controlled repair reasons. An image review applies approved or rejected. Any image concern leaves its bytes private. A rights, legal, safety, or privacy failure produces rejected. Reviewer output may cite a stable public query URL when its parameters identify a document or database result. It cannot persist a signed preview URL, credential-bearing query parameter, OCR text, private reasoning, or unrecognized free-text field.

The review job and its decision are durable. A provider failure creates no content decision, so the subject keeps its submitted or uploaded state. Rate limits and upstream failures wait five minutes, a busy provider waits 30 seconds, and provider-credit or local-budget holds wait one hour. Cases proven to precede a provider request return automatically with their exact job identity. A terminal packet failure with a provider receipt follows the fresh-cycle recovery below. An ambiguous paid-call failure or invalid paid response stays closed as an operations incident.

A packet receipt that reaches terminal_failed with expired_in_progress_outcome_unknown remains immutable with its dead job. The state means the provider may have completed or charged for the call without returning a durable result. A packet receipt that reaches terminal_failed with provider_failure also stays closed when a receipt proves that the provider adapter began the request. The provider may have charged for that call before the adapter failed.

After checking the provider record, an operator may open an append-only packet review cycle for either incident. The cycle keeps the proposal state unchanged, records digests of the prior job and receipt snapshots, and adds its event identity to the decision binding. It creates a fresh job, receipt, and decision identity. A decision bound to an earlier cycle cannot approve or publish the current cycle. A provider failure that occurred before any receipt exists may return through the same decision identity because no provider request began.

Unknown-outcome recovery requires a database-bound dry-run digest and the exact typed authorization AUTHORIZE_NEW_PACKET_REVIEW_CYCLE_AND_SECOND_PROVIDER_CALL. Terminal provider failure recovery requires the same digest binding and REQUEUE_TERMINAL_PROVIDER_FAILURES. Either authorization permits one fresh paid provider call for the selected incident. Apply rechecks the packet head, proposal identity, prior job, receipt, and recovery event under the canonical proposal lock.

A compatibility check covers one terminal provider failure that an older operator command already returned to the same decision identity. The check requires its recovery event to be the latest job event, unchanged job attempts, no lease or job-budget reservation, and no later spend for that decision. Every earlier spend row must already be settled or released. The plan binds the complete ordered spend-row baseline by count and digest. The receipt may be untouched, or it may show exactly one later claim that the local budget rejected before creating any spend event or contacting the provider. That second shape requires the receipt attempt count to equal the job attempts plus one, unchanged request and provider identity, executable reconstruction of the exact request digest, no result, and no later proposal event. Later local-budget replays restore that exact retryable receipt snapshot. Apply closes the old job and receipt again, appends the typed supersession audit, then opens the fresh cycle in the same transaction. Any other changed field or later activity stops recovery. If event append succeeds and enqueue fails, the command exits unsuccessfully and reports reconciliation required. A later dry run produces a schedule_existing_cycle plan that queues the same cycle without appending another event.

One older reviewer-policy job may already be cancelled in that same pre-cycle lane. It does not block provider-failure recovery only when its exact durable job specification identifies the stale policy, its sole receipt attempt is bounded by a local provider-budget deferral, and the complete job history ends in the standard stale-policy cancellation. The job must have zero provider spend, zero job reservations, and an executable request digest. The dry-run plan binds the job, receipt, event stream, spend baseline, policy mismatch, and source-state event. Apply rebuilds that proof under locks, and the new immutable packet review-cycle event retains the proof and its digest. The ordinary compatibility path binds the same-receipt recovery event. The exact manifest terminal form binds its final dead-letter event. A second cancellation, a provider outcome hold, an active job, or any later evidence change stops recovery. The nonempty review_execution_epoch is part of this execution identity. A different nonempty epoch counts as historical activity only when a succeeded job and completed receipt have an exact canonical job specification, result, cycle binding, decision, executable request, provider, and model match, and both finished before the recovery source was created. A distinct cycle is historical only when it is the initial cycle or an immutable predecessor restart event on the source cycle’s chain for the same proposal. Active, incomplete, fabricated, or malformed evidence blocks recovery. An equal epoch is competing activity.

Six manifest-pinned compatibility records may lack an execution epoch. Each exception is limited to its recorded v1 job, decision, proposal, revision, content and validation digests, published head, policy, prompt, reviewer lane, model, code version, and durable specification. Executable reconstruction must reproduce the job identity, specification fingerprint, decision identity, result digest, full five-event job history, and the immediately following non-authoritative content-review proposal event. The proposal was already published before the job claimed work. The local result applied no decision and opened no provider request. A provider receipt, spend row, budget reservation, provider-shaped result field, extra pre-epoch job, changed job or event, or later proposal event rejects the exception. Every other missing or malformed epoch stops recovery.

The frozen manifests identify one staging campaign incident and five production campaign incidents. Selection requires one exact proposal and source-job pair, and an ambiguous pair rejects both. Missing pins never authorize substitution of an analogous proposal, job, decision, receipt, or event from either environment. An unregistered seventh pre-epoch record remains a blocker.

That same immutable proof may clear the exact manifest source after its current job and provider receipt have both returned to their canonical terminal provider-failure state. This terminal form changes only the source-state predicate. Every manifest pin, historical no-call check, current packet-head check, receipt binding, and competing-job check remains required. The dry-run binds a reader capability for this form, and apply checks that capability in its local packet-cycle reader. The staging manifest’s single pinned cancelled stale-policy job may accompany its terminal source after the operator rebuilds its complete zero-spend, zero-reservation, local-budget, cancellation, job, receipt, and event proof against the exact terminal dead-letter event. The production manifests have no stale-policy sibling. An extra cancelled job or any changed field stops recovery. Every serving reader must run the capable release before apply. Earlier readers reject the truthful terminal-source event.

Before apply, the operator records the deployed Git SHA and image digest for both serving web Machines and proves that both expose the required reader capability. Once the terminal-source event is durable, that release becomes the reader floor. Incident recovery must move forward on the recorded SHA or a compatible descendant. The b406 release and other incompatible images are forbidden rollback targets after apply.

The dry-run plan stores the complete compatibility proof and digest. Apply takes the existing provider, job, event, spend, reservation, and proposal locks, rebuilds the proof, and requires an exact match before opening a new review cycle. It writes the immutable cycle event and successor job in the same transaction, including the successor’s first durable event. An enqueue error rolls back the cycle. A legacy cycle without that job is invalid and cannot use pending-schedule resume. The restart event retains the proof and its digest. These exceptions cannot authorize another legacy record or an outcome that may have contacted a provider.

All packet review workers must remain at zero during this operation. Operators must not issue manual SQL or another recovery command that changes the pinned job, receipt, spend, reservation, job-event, or proposal-event evidence. The budget preflight may reconcile daily admission-budget rows. It creates no reservation and makes no provider call. After apply, recheck the exact evidence and prove that the fresh successor is the sole leaseable review_research_packet job. Run one background worker with the count bound --max-jobs 1 and exact ID bound --expected-job-id <successor-id> (or the deployed equivalent). The command must exit without claiming another job when that exact job is unavailable or ineligible for the selected queue and workload. The claimed and completed job IDs must exactly equal the successor ID. Stop that worker before starting the ordinary fleet.

Hourly reconciliation takes an oldest-first snapshot of submitted packets, uploaded images, approved subjects, and current published heads. It skips current approvals, repairs missed enqueues, sends stale approvals back to Luna after a policy, prompt, model, or lane change, and cancels obsolete jobs. A current head without a current Luna receipt remains durable while live packet reads and the packet directory withhold it. Workers lease the oldest eligible Luna job first. An enqueue failure makes maintenance degraded and retryable, so the durable maintenance job and the next hourly snapshot try again. Recent completions suppress the short queue-age alert for a healthy backlog. An eligible subject that waits 24 hours reaches the hard staleness alert even while other Luna jobs complete. Active provider-credit and local budget holds keep their dedicated warning during the cooldown.

A Luna-approved image owned by an inactive or suspended account stays private in uploaded state. Its quarantine object and exact review receipt remain available. Reconciliation applies that same receipt when owner eligibility returns, or queues a fresh Luna decision if the policy identity has changed.

Packet and image decisions never enter a staff-review queue. The REST routes POST /v1/research/packet-proposals/{proposal_id}/review, POST /v1/research/assets/{asset_id}/review, and GET /v1/research/assets/{asset_id}/review-preview return HTTP 410 with automatic_luna_review and consume no review quota. MCP discovery has retired review_research_packet_proposal, review_research_asset, and get_research_asset_review_preview.

The guarded packet-quality campaign runs while judging workers are stopped. For an existing head, it invokes the same Luna review synchronously for a submitted or stale approved release proposal, then applies the ordinary publication checks to an approval. Other Luna outcomes keep that release entry hidden and record a terminal review outcome. Campaign completion requires the exact 300-packet floor and a drained Luna review cycle for every entry. It does not convert changes_requested or rejected into approval, and those heads stay out of live packet reads until a corrected proposal earns a current approval. Application deployment does not inspect this campaign state.

Each controlled decision is copied into the append-only proposal or asset event, including policy, prompt, provider, model, reviewer lane, subject binding, checklist, outcome, and reason codes. Publication rechecks the current approved lane, complete attestation set, validation digest, and live packet head. A provider failure, changed binding, incomplete checklist, unapproved lane, or stale head cannot publish content.

Publication accepts only an approved proposal. It compares the proposal base with the live head inside the same database transaction. A stale approval fails and returns a conflict. The approval event must also name the proposal’s validation digest. The reviewer then compares a new proposal against the newer head.

Every publication locks and rechecks each attached image for a current Luna approval in the same transaction as the head move. A bundled first release also checks its linked problem state. The problem must be published.

The head version increases by one for every successful publication. Historical revisions remain readable by identity. Public pages and packet manifests expose the revision identity and head version that supplied the displayed content.

Publication also projects every packet object, target binding, relation, contributor credit, and retrieval document into canonical research memory before the head moves. The projection and head comparison share one database transaction. Replaying a published revision repairs missing graph members and leaves complete members unchanged. A proposal that removes an existing graph member fails closed until canonical retirement semantics exist, which keeps the packet head and the default research loop aligned.

The first published packet proposal from a verified account on each problem creates one provisional 5-Reputation curation award. The award cites the publication event, belongs to the proposing account and agent, and becomes final after the standard 14-day review window. Later packet revisions by the same account on that problem create no additional award. Operator-only and unverified service accounts earn no competitive Reputation. Publication and startup reconciliation apply the same idempotent rule so historical eligible releases receive the award once.

Checked-in fixtures and availability

Reviewed fixtures seed the first live heads in a new database. A seed operation leaves every existing live head untouched. Package deployment therefore cannot replace content that has entered the live publication workflow.

The release-300 bootstrap may admit the exact historical validation exceptions recorded in Problem packet rules. The package release command binds that admission to the reviewed manifest, fixture, candidate, and failed-check digests. It records the binding in the database-bound plan and bootstrap authority reference, then sends the complete candidate through the ordinary Luna review. The admission applies only when no live head exists.

The built site contains the reviewed fixture projection as a fallback. At runtime:

a successful packet API response replaces the built projection;
a missing packet or unavailable API leaves the built projection visible;
the research directory follows live heads and falls back to its built rows;
publication requires no Astro build or site deployment.

Changing renderer code, schemas, or the bootstrap set still requires the ordinary software release process.

Research image contract

This contract applies to each image a contributor elects to supply. A problem or first packet may omit images and use the labelled grey Mandelbrot placeholder in every problem figure slot that needs a fallback. Supplied art keeps the complete review and rights requirements below.

An image registration includes:

SHA-256 digest and byte size;
PNG, JPEG, or WebP media type;
pixel dimensions when the client can determine them;
alt text and caption;
license, rights basis, source URL when applicable, and contributor provenance;
problem reference and stable public HTTPS URL.

The asset identity is derived from the problem reference, content digest, and canonical metadata digest. PostgreSQL stores metadata and history. Image bytes stay in reviewed object storage. Each metadata identity receives its own object key, even when two registrations contain identical pixels. This keeps a later caption or rights correction isolated from the object reviewed under the earlier metadata. A configured object store issues a short-lived signed upload request. Development installations without managed storage may register an existing HTTPS copy when the contributor supplies the matching file for local hashing.

Managed uploads enter a private quarantine bucket. The signed request binds the object key, media type, byte length, SHA-256 metadata, and cache policy. TheoremDB reads the complete stored object, checks its digest and declared size, parses its container, decodes its pixels, and rejects animation, embedded metadata, trailing data, or unsafe dimensions before the upload enters review. Luna receives a short-lived private preview and checks the image, descriptive text, source, and reuse rights. Approval copies the verified bytes to a separate public bucket. Unapproved records and public APIs expose no storage key, public URL, or private preview.

Only an approved asset can appear in a packet candidate. The packet attaches it by asset_id and one role: research_figure, diagram, plot, photograph, or source_scan. An optional record_slug associates the image with one packet record. Public packet responses hydrate the attachment with approved metadata.

Replacing pixels, alt text, caption, license, or rights information creates a new asset. Packet revisions that use the former asset remain reproducible.

An administrator can take down an approved public object while preserving its immutable review history and private restore source. Restoration revalidates the retained bytes before opening a new Luna upload-review cycle. Luna must approve that cycle before the bytes return to the public bucket. Scheduled storage reconciliation restores a missing public copy for an asset with current approval, removes a public object whose record is unapproved, retries rejected-upload cleanup, and removes an uncompleted quarantine upload after 24 hours. Every moderation event and reconciliation action has a stable machine-readable action and reason code.

Machine-facing response rules

Every public release response includes:

the release schema;
problem reference;
immutable revision identity and content digest;
parent revision when one exists;
published head version and timestamp;
complete packet JSON;
hydrated approved asset attachments.

Every proposal response includes its base and candidate revision identities, current state, ordered events, and semantic diff. Every actor field preserves account and agent identity when available. Human labels are projections of controlled stored values.

Clients treat the API response as authoritative and the built packet as a documented fallback. A client never merges two revisions field by field.

Release checks

A change to this workflow passes all of these checks:

PostgreSQL and SQLite schemas agree.
Revisions, proposals, and events reject update and deletion.
Packet and relation validation runs before revision insertion.
Every submitted proposal stores a validation report bound to its candidate digest.
Blocking report failures prevent submission.
Unapproved assets cannot enter a candidate.
A current independent Luna review or exact verified-operator import authority is required, including the separate publication authority for an exact verifier-authorized Lean append.
Approval records every pending attestation and the validation digest.
Concurrent proposals cannot move a head past a stale base.
Existing heads survive fixture bootstrap.
HTTP and full MCP operations return the same stored records.
Statement pages, the homepage packet, and the research directory consume live heads and retain tested fallbacks.
A proposal can be published and read by an already-built web bundle.
A new problem and first packet can share one idempotent pending bundle.
Bundled packet publication waits for problem qualification, packet approval, and approval of each supplied image. A bundle with zero images satisfies the image condition.
A newly published packet is immediately available through default MCP orientation, search, problem digest, and record lookup.
Managed image bytes remain private until approval and use distinct quarantine and public buckets.
Image completion performs full container and pixel decoding under explicit byte, dimension, metadata, and animation limits.
Takedown, restoration, and storage reconciliation preserve the audit history and fail closed when public and private storage disagree.
Packet decisions bind either the current Luna policy, prompt, model, lane, candidate, validation report, and pending attestations, or the exact administrator import, plan, candidate, validation report, attestations, and image approvals.
Image decisions bind either the current Luna identity and upload or restore cycle, or the exact administrator import, plan, position, bytes, SHA-256, and rights metadata.
Hourly reconciliation repairs missed enqueues and stale approvals in oldest-first order.
Direct review and review-preview REST paths return 410, and their former MCP tools stay outside discovery.
Packet provider-incident recovery requires the matching typed authorization and exact plan digest, preserves terminal source rows, and creates a cycle-bound decision identity. The compatibility path re-closes an untouched same-receipt requeue with an append-only audit and binds any single proven stale-policy local-budget cancellation into that cycle audit.
Verified-operator finalization accepts one OAuth-bound bundle per request, recomputes the exact review-receipt digest, rechecks receipt identities inside both write transactions, grants no reputation, and safely reconciles an exact partial or automatic publication.
Verified-operator content import requires a stored dry-run digest and typed confirmation, durably queues generation-fenced item jobs, rechecks every item before its transition, records the distinct administrator authority without fabricating provider review, and creates the collection last.