Skip to main content
After a research run completes on the worker, the control plane on the VM can generate or rewrite structured paper artifacts when paper rows and evidence context are available. This process - optional evidence sync, artifact writing, packaging/provenance scanning, and publication automation - is the finalization stage of the Enoch research loop. The output is a Markdown and LaTeX draft that should be grounded in run notes, metrics, evidence bundles, and claim ledgers collected during the experiment. For current runtime topology, worker path, and decision-artifact boundaries, see current runtime snapshot.
Do not publish generated artifacts until corpus import, index building, packaging/provenance lint, and strict claim/evidence audit status are explicit. Every artifact produced by this pipeline is AI-generated from automated run data. It is not human-authored and has not been peer-reviewed. The operator claims no personal authorship credit for generated prose or claims.

​
1. Confirm evidence exists

A complete corpus artifact usually includes paper.md, metadata.json, evidence_bundle.json, claim_ledger.json, and paper_manifest.json. Do not treat a draft as publishable if evidence or claim-ledger files are missing without an explicit explanation. Before the artifact writer runs, the control plane should have access to the evidence the worker produced. If paper_evidence_sync_enabled is true, evidence sync runs when you trigger a draft rewrite; you can monitor its outcome in the rewrite response. When evidence sync is enabled, the control plane attempts an HTTP sync first, reading evidence files directly from the worker-gate API. If the worker returns the evidence, it is written into the local artifact root under the project directory. If the HTTP sync cannot retrieve the required high-signal evidence files, the control plane falls back to SSH, streaming a bounded tarball of evidence artifacts from the worker’s project directory. Evidence paths the control plane looks for include:
The HTTP sync retrieves specific high-signal files from results/ (e.g. hot_cold_sim_results.json, smoke.json) rather than the entire directory. The SSH fallback syncs the entire papers/ directory plus specific result files. If paper_evidence_sync_enabled is true in your config and no local evidence is found after sync, POST /control/api/paper-reviews/{paper_id}/rewrite-draft returns HTTP 424 with an evidence_sync detail object explaining what was tried. POST /control/papers/draft-next skips those candidates and returns action: "noop" with skipped details instead of HTTP 424.

​
2. Generate Markdown and LaTeX

Once sufficient local evidence is present, the artifact writer runs against the evidence bundle and claim ledger to produce:
  • papers/<run_id>/paper.md — Markdown draft
  • papers/<run_id>/paper.tex — LaTeX draft
  • papers/<run_id>/evidence_bundle.json — Evidence bundle
  • papers/<run_id>/claim_ledger.json — Claim ledger
  • papers/<run_id>/paper_manifest.json — Artifact manifest
The writer uses the model and provider configured under paper_writer_* settings. To test Synthetic.new with GLM-5.1, use:
If paper_writer_fallback_enabled is true, the writer falls back to a deterministic MVP draft if the configured provider is unavailable or returns an error.

​
3. Scan packaging/provenance checks

After the artifact is written, a publication automation record may still expose legacy fields such as review_status with values like unreviewed or triage_ready. Treat those as raw compatibility/detail fields, not the operator work queue. The packaging/provenance check includes a ranked checklist of items the automation lane must pass, fail, or accept as a recorded risk before the paper can be finalized. It does not validate peer review, scientific correctness, or independent replication. Current publication automation queue showing automation states, paper states, rank score, and checklist progress You can dry-run the next paper-positive write candidate. This is not a queue listing; it answers whether any completed run is currently eligible to become a first draft:
Use dry-run first. In current deployments this path should remain explicit and bounded; unattended timers should stay disabled unless you intentionally re-enable them for a controlled drain.

​
4. Finalize generated drafts

Paper automation APIs support claiming automation items, updating checklist items, changing raw automation state, rewriting drafts, marking papers ready for finalization, and preparing finalization packages. The dashboard presents the simpler operator lanes: write, finalize, publish/import, published/imported, and done/no paper. Generated prose remains AI-generated and not peer-reviewed. Current papers queue showing generated draft paths, claim ledger paths, and manifest paths

​
5. Rewrite with an optional provider

If configured, synthetic.new can rewrite draft content through an OpenAI-compatible endpoint. Keep paper_writer_fallback_enabled and deterministic fallback behavior in mind when interpreting output.

​
6. Apply corpus gates

The corpus packaging/provenance policy rejects placeholder citations, fake citations, peer-review claims, implied human authorship, and missing metadata files unless explicitly stated. The strict claim/evidence audit is separate: it requires non-empty evidence-linked claim ledgers and public or explicitly unavailable result-file references.

​
Current snapshot

The public corpus currently reports 388 canonical indexed artifacts, 388/388 packaging/provenance lint passes, and 388/388 strict claim/evidence audit passes. Counts can change as corpus import, packaging/provenance lint, and strict audit reports are rerun.