Research packet publication

Packet and image review use Terra at low reasoning. Older workflow names in this document still say Luna. Each decision records the configured model, and retained receipts keep their original identities.

Status: active

Version: theoremdb-packet-publication-v4

Revision date: 2026-08-30

Applies to: live packet releases, proposed packet changes, packet review, publication, and research images

Rules index: TheoremDB rules

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 one-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, optional 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.

An image-free item uses assets: [] in both its item and packet. An image-free ZIP contains only manifest.json. Supplied images still require an exact match across archive files, packet attachments, and the stored bundle asset set.

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-terra evidence-review lane. Luna is independent of the contributor and records approved, changes_requested, rejected, or inconclusive 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.

Saved results may enter this same proposal path through preview_saved_contribution and publish_saved_contribution. The contributor selects saved record IDs and explicitly requests research publication or complete resolution of a selected claim. The server copies the current packet and bounded stored dependencies. For a claim without a body, it can reuse the exact trace of one same-result attempt only when a stored reports edge and matching producer digest bind them. The preview names that argument source and binds every source hash, the base revision, canonical target and validation policy. A complete-resolution candidate requests acceptance of the full claim while preserving evidence grades and source bylines. It still needs independent exact-scope review and ordinary publication before the canonical status changes.

Submission requires the exact preview digest and an account-bound idempotency key. Source or head drift requires a fresh preview. The proposal’s unique identity and submitted event bind that key to the request in the same write transaction, after current credential and locked source checks. An exact retry returns the committed proposal and can repair an interrupted review enqueue through the existing durable review identity. Preview consumes no write quota. Authenticated REST preview supports the complete candidate; Actions carry saved IDs and a bounded source manifest. Cross-project curation and ambiguous legacy layouts use the full packet editor.

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. The full-packet REST preflight advertises supports_preflight_confirmation: true. Its matching proposal POST accepts the optional expected_preflight_digest and rejects candidate, validation or readiness drift with a conflict before saving or scheduling review. It repeats that comparison under the write fence. Older clients may omit the field. 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.

Website research contribution contract

The public website accepts theoremdb-contribution-v1 research-result envelopes through POST /v1/website/contributions/preview and POST /v1/website/contributions. An account session authenticates the person. The server validates the exact target, evidence, scope, source references and contribution license, then builds the packet candidate from the current head. The imported envelope contains only new work. It cannot assign account or agent IDs, controlled verification grades, packet relations, retrieval impressions or canonical state.

Preview is deterministic and stores no submission, creates no retrieval impression, charges no write quota and schedules no model review. It displays the actual person, declared model use, license, public-record visibility and separate publication readiness. A bounded source selection cites only records whose canonical targets remain public. Confirm rechecks the canonical state, packet head and immutable source fields under the write fence.

save_checkpoint persists the research graph, account-scoped request and model declarations atomically. The person owns the records. Model participation is contributor-reported and carries no execution or correctness authority. Structured model declarations stay outside the mathematical record hash. submit_for_review explicitly consents to saving the checkpoint and proposing its exact preview for the existing independent packet review. A later submission uses the saved request’s publication-preview and publication-confirm endpoints.

The website result builder includes an artifact’s authored scope, companion argument, stable source locator and explicit dataset metadata before computing content IDs and credit receipts. An absent source URL remains absent when the result enters a packet. Ordinary research publication preserves those content hashes. The existing controlled complete-resolution path retains its reviewed claim-status and resolution-metadata transition.

Older checkpoints keep their original identities and scope. When their publication would change hashed content, preview explains how to import a corrected contribution with distinct record IDs. It must not add scope under an existing artifact ID. Blocking validation checks retain their exact paths and messages in the website preview.

When public problems share a packet project, the selected problem’s exact current approved packet may authorize a secondary project binding. Preview remains write-free. Confirmation rechecks that approval and head, then adds the binding within the checkpoint transaction. The primary target, existing record identities and routing remain unchanged. A secondary binding alone grants no authority to save against a withdrawn or unapproved target packet. Preview and publication reject stale shared-record content, including a sibling’s later publication that leaves the selected problem’s packet head unchanged.

Each confirmed request has one stable proposal identity. Exact retries recover its saved records and any proposal committed before a response or queue failure. A changed preview needs a new confirmation. A save followed by a publication failure remains a visible saved checkpoint with a retry/repair receipt. Review changes requested are shown as needs_revision; revised mathematical work uses a new contribution and retains the prior record history.

The full packet editor preserves these saved source records too. Packet preflight and submission reject changes to their hashed content under an existing slug, with exact field paths and saved_contribution_requires_successor checks. Publication repeats that guard for older candidates. A correction creates new contribution records and credits its sources with used_record_refs; the original receipt, proposal, record content and model declarations stay available. Packet relevance and attribution annotations remain outside the mathematical hash. The controlled complete-resolution selection may still establish its selected claim and add its resolution-coverage explanation after review, while preserving the saved argument, evidence, scope and existing metadata. Generic packet editorial records keep their existing reviewed projection workflow.

A blocked saved-content correction can read a bounded public source template through GET /v1/website/correction-source?problem_ref=...&record_ref=.... It reconstructs one website attempt and its claim/artifact companions through their exact stored graph and content identities, and retains every original public source-credit endpoint. It reads no private request envelope. The DTO uses the same public identity projection as public record reads. Original authors and reported models appear as source attribution; a new draft starts with empty model declarations and ordinary research publication intent. Original replay facts remain source material until the contributor supplies evidence for the corrected work.

The optional outer correction_source binding on website preview and confirmation contains the exact selected record ID and public source digest. Preview and the ordinary save fence recheck that source graph, public availability, retained citations and source license. This flow requires a change in normalized action, outcome, summary, trace, claim, scope, artifact, failure or execution. A source/model/intent/license-only change cannot satisfy that check. This is an exact field comparison, not a mathematical novelty judgment. A successful save creates fresh contribution identities with the current person’s authorship and original source credit. It grants no supersession, publication or verification authority. Exact committed retries recover the same receipt before revalidating current source availability.

Reconstruction fails explicitly when a source is unavailable or superseded, a graph is ambiguous, a saved content hash changed (including an older controlled-resolution transition), or complete source credit cannot fit the existing import limits. It never drops a source or silently truncates work. Missing legacy license or workflow fields require an independently prepared new result with explicit source credit. Private context, prior review decisions and complete-resolution requests are not reconstructed. A resolved canonical target may require a different explicitly chosen allowed research intent before the normal preview can pass.

The website may build a first packet for an existing public target. Its first presentation requires a supplied mathematical claim describing the result and unresolved boundary. A negative trace without that claim can still be saved as a checkpoint. Cross-project prior work remains an immutable source-credit edge and a precise citation, without copying its whole graph into the packet. A complete-resolution request supplies its full argument, original scope and an explanation of the canonical acceptance conditions. Independent review checks coverage before any canonical resolution change, including exact finite targets whose scope is bounded. Existing connected clients retain their current contracts.

The envelope has a 1,000,000-byte normalized UTF-8 limit, one research work unit, at most 50 used-record references, 20 structured citations and 20 model declarations. Existing record field and evidence limits remain in force. Private request reads and account export require the owning account. Account deletion removes private request payloads and model declaration associations while preserving the existing public contribution deletion policy.

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.

A current published initial revision may carry a compact v3 or v4 package report whose changed-record details were omitted. The reader reconstructs those details only after checking the stored report digest, exact problem and content digests, current proposal and revision, and recomputed record count. Complete validation under the current rules must find no hard failures. The nonempty bootstrap source reference stays in the audit record and grants no review authority. The derived report retains the original validation digest and adds its own review validation digest. Every newly generated attestation still requires the current independent review before the packet earns a current approval. Other report shapes and changed inputs remain unavailable for review until a corrected proposal is submitted.

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 review cycle is terminal. The contributor repairs the controlled reasons in a successor proposal against the current head, with a fresh candidate digest and Luna job. The owner may instead explicitly request another independent review of the unchanged, unpublished candidate through the confirmation workflow below. This appends a new cycle and preserves the earlier decision and immutable source.

An inconclusive review records an incomplete assessment without inventing an author correction. It preserves the proposal’s existing lifecycle state and candidate. Its append-only review event is terminal for that exact review cycle. The event’s applied flag means the disposition was stored. It grants no approval. A later inconclusive review supersedes an older approval for current publication selection, including an already published head. Ordinary scheduling, maintenance, queued duplicates and direct provider retries must retain that outcome without a new paid call. A later paid attempt requires an explicitly authorized fresh cycle.

An authenticated owner can read review_request_capability on the proposal and POST /v1/research/packet-proposals/{id}/review-requests/preview with expected_decision_id. This preview performs reads only. A ready preview returns expected_preview_digest and asks for confirmation that the normal review allowance and provider budget will fund a new review. Owner requests set the additive owner_review_requested lifecycle state, which older maintenance readers exclude. The prior mathematical decision remains in history. Owner requests use review_owner_research_packet on the existing judging queue. Only workers that understand the immutable owner request may claim this type. Its reviewer, packet-wide budget and shared per-account content-review allowance are the ordinary packet review limits. Maintenance does not create replacement paid jobs for owner cycles. A failed owner request remains visible for operator inspection. The existing digest-confirmed usage-exhaustion recovery can requeue its exact job after validating the owner event and provider receipt. Historical operator cycle manifests do not authorize new owner cycles or generic paid retries. The owner confirms by POSTing to /v1/research/packet-proposals/{id}/review-requests with expected_decision_id, expected_preview_digest, a stable idempotency_key, and intent: "request_new_review". Retain the same key and body after an ambiguous response. The narrowly typed review_request_refusal with schema theoremdb-owner-review-refusal-v1 may permit a fresh explicit preview. It binds the refused proposal, decision and preview digest, sets request_recorded: false and safe_to_repreview: true, and is returned only after owner authorization and existing-request lookup under the proposal locks prove that the key has no recorded request and the current preview digest differs. A committed key returns its receipt even after a policy change. Generic conflicts and timeouts do not authorize discarding a key.

This operation accepts only an unpublished changes_requested proposal or a submitted or owner_review_requested proposal whose exact latest review is inconclusive. Current owner credentials, the previous decision, immutable candidate and validation report, published head, and normal review admission are checked again under the write fence. A changed head requires a successor proposal. Approved, published, rejected and withdrawn proposals cannot use this operation. A rules-version change still requires a new proposal and validation report.

Confirmation appends an owner-request event with schema theoremdb-owner-packet-review-cycle-v1 and a new decision identity, sets the current lifecycle to owner_review_requested, and atomically enqueues the ordinary review job. Earlier events remain unchanged. A replay or an existing active owner request returns that same request before new policy or budget admission. Each completed terminal cycle needs a fresh preview and explicit owner intent to start another review. Background maintenance cannot create these cycles. The endpoint does not call a reviewer synchronously.

Queued, running and waiting requests show their current job status. A dead-letter or exhausted job shows failed, cancellation shows cancelled, and a succeeded job without a saved decision shows unavailable. These terminal requests remain visible with recovery.action: "operator_review_required" and automatic_retry: false. Their preview cannot authorize another review. The owner can refresh the proposal and retain its request ID for an operator to inspect the exact job and provider receipt. The existing provider-incident recovery rules below govern any eligible repair and its separate typed authorization. Cancellation or a missing decision alone grants no additional provider call.

Proposal reads expose review_status and review_feedback, bound to the latest exact candidate and review cycle. Website receipts copy these fields at the receipt root. Bundle summaries copy them into components.packet; an inconclusive packet keeps the bundle pending. Legacy or unreviewed proposals expose awaiting_review and null feedback. Unreadable review-cycle history exposes unavailable and null feedback while retaining the saved proposal for diagnostics; publication and provider admission still reject that history. Feedback uses schema theoremdb-packet-review-feedback-v1 and contains the decision ID, recorded outcome, controlled message, checks, issues, deterministic validation blockers, specific_changes_available, and automatic_retry: false. Existing state, publication URLs and saved record IDs remain intact.

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-terra. 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.

New packet reviews use the packet-only theoremdb-content-review-checklist-v12 format. Image reviews retain v10. Format compatibility is explicit: v10, v11 and v12 packet approvals can remain authoritative only under their original decision hashes and the current content-review policy, provider, pinned model version, independent lane, exact candidate/report/attestation binding and current review cycle. Supporting an older format never rewrites its receipt or substitutes v12 into its identity. Unknown formats and revoked authority remain invalid. A format-only update does not schedule a re-review of a supported current approval. Retained v10 and v11 provider responses can replay only through an existing completed receipt with its exact original request digest; the historical reconstruction paths cannot claim or retry a fresh paid request.

For current packet reviews with structured bibliography rows, the reviewer may look up submitted works by their bibliographic identities and follow public citations and redirects across domains. A contributor’s TheoremDB record URL must not confine these searches to TheoremDB. Lookup retains the existing tool-call and budget bounds, requires an observed public source open for bibliography-backed approval, and preserves exact submitted-URL checks when URLs are present. Search snippets alone cannot establish source support. This permission does not require an unrelated independent source for an original result. Historical decisions and completed provider receipts remain unchanged, and this transport repair does not schedule new reviews of terminal cycles.

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 records approved, changes_requested, rejected, or inconclusive. Deterministic blockers or a validated, located author correction produce changes_requested. An unconfirmed check or non-affirmative recommendation without a concrete correction produces inconclusive. All six checks must still be confirmed for approval, with no adverse reasons or findings and all existing evidence and independence predicates satisfied. A required Python replay that never ran may be retained only as an explicit inconclusive reviewer limitation with artifact_evidence_reviewed unknown and no author-correction findings. Approval still requires the actual replay. 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 packet prompt defines each check and includes every changed record’s complete before/after values, changed relations and sections, a compact operation/path manifest, and the server’s exact validation bindings. exact_diff_reviewed means inspecting all those changes. The server checks immutable digests and coverage. The reviewer can report missing comparison or context without alleging a defect in the submitted work.

Provider packet findings are limited to 16 controlled issues. Each issue binds a check, a known issue code and a supplied stable location ID. Content locations identify record slugs and semantic paths, exact relation triples, or named sections. Review limitations identify the unresolved check. New v12 issues also require diagnostic (20–1600 characters) and requested_change (20–1200 characters). These are intended final public feedback: a concrete explanation at the named location and the requested edit or missing review context. A category restatement alone is insufficient. The adapter preserves this text in its completed receipt and append-only event. The public projection returns it as message and action. Clients must render both as literal text through text nodes or HTML escaping, with no HTML or Markdown interpretation. Mathematical inequalities and tag-like notation remain literal text; text validation does not infer markup.

Every failed or unknown check should have an issue explaining the unresolved condition, including inconclusive reviews. Source-support feedback names the affected claim, source and locator, what could be checked, and the passage, assumption, argument or tool result needed to complete review. An observed missing source open or required corroboration check produces a reviewer limitation. It cannot establish that the author’s claim lacks support. Original work retains its evidence grade and does not acquire an unrelated-source requirement through feedback guidance.

When an otherwise valid response omits an explanation, preserve the terminal decision and add clearly labelled suggested checks for each unexplained checklist item. These suggestions identify the feedback gap and cannot establish an author correction or approval. The public projection may contain the 16 provider findings plus at most one such advisory for each of the six checks. It preserves every supplied finding. This fallback schedules no additional provider call.

These two fields admit no additional model-output fields, private reasoning, raw traces, credentials or private URLs. A URL must exactly match a safe returned evidence reference or a public corroborating URL observed during this review. Output size and text validation apply before receipt completion and again before event storage. An explanation cannot establish execution: the existing observed-tool requirements still apply. A review limitation must describe missing context without inventing an author defect. Historical v10/v11 issues keep their original controlled explanations. The read projection may append labelled suggestions to a generic review limitation’s action, while the stored decision and receipt remain unchanged. Unknown codes, mismatched checks, unrelated locations and duplicate provider findings remain invalid. The public projection carries the validated locations and final feedback. Historical decisions remain immutable; a legacy request for changes with no located finding truthfully exposes specific_changes_available: false. Clients still report reviewer limitations and their next steps when that flag is false, retaining each finding’s path, explanation and action.

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.

An inconsistent immutable packet review envelope fails its job immediately with packet_review_binding_mismatch, before contacting the provider. The proposal and its validation report remain unchanged. The terminal job and append-only failure event remain available for operations diagnosis. This failure consumes no review cost and does not defer other proposals. Provider outages and temporary readiness failures retain their existing retry behavior.

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.

A later terminal provider failure may receive another explicitly authorized operator cycle. Every earlier terminal failure must belong to the same proposal’s audited predecessor chain, with at most 32 links. The proof binds its original request, immutable failed receipt, full job-event history, settled or released spend, and direct recovery event. It requires zero active job-budget reservations. Apply recomputes each proof under the existing locks and rejects any changed evidence. Historical rows remain unchanged. This exception grants no automatic paid retry and retains the exact database-bound digest and typed authorization.

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 an authority policy, unsupported format, 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. Accepted-proof discovery applies the same current publication approval gate before ranking or limiting results. A stored resolved presentation alone cannot place a withheld head in Recent proofs. Workers lease the oldest eligible Luna job first. Scheduling records distinct outcomes for a saved review identity, a subject that became ineligible, an enforced paid-result or budget hold, and an actual enqueue failure. Benign skips and existing holds keep their diagnostics without failing maintenance. A real enqueue or reconciliation failure leaves maintenance degraded and retryable after independent publication, compaction, memory projection, and ingestion phases finish their own checks. The durable error retains bounded subject samples, complete controlled reason counts, omitted-sample counts, and phase-completion status. The next retry and hourly snapshot retain the same review identities and paid-call guards. 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. Current inconclusive cycles are terminal and are excluded from this reconciliation queue. A completed prior provider receipt whose decision has not been applied retains an explicit review_provider_result_unapplied hold across policy changes, including cancellation of its old job. It cannot release another paid call. The receipt and source job remain available for exact outcome reconciliation. A normal replay by the original current worker can still apply its cached result. A revoked source cannot grant current approval.

Recent proofs also includes public complete-proof proposals while their latest event is submitted, approved, owner_review_requested, or changes_requested and their base still matches the current head. These rows use their submission date and a Pending review or Changes requested label. Rejected, withdrawn and stale proposals are excluded. The selected claim must retain its complete-target scope, proof material and immutable identity. Candidate content cannot grant accepted status or a problem-level Lean verification badge. Published pending claims retain the same current publication approval gate as accepted proofs. A visible changes_requested candidate retains its terminal review outcome and the ordinary successor or owner-request workflow.

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 explicit, cursor-bounded historical reconciliation apply the same idempotent rule so eligible releases receive the award once. Process startup does not scan historical packet publications. Verified-operator imports receive no curation award.

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.