Meta3 Process

Meta3.0 improves the meta process, not only the amount of compute.

Meta2.0 answered: "Can we digest Samuel's session corpus at all?"

Meta3.0 answers: "Which conclusions are valid enough for Samuel to use?"

Process Loop

Requirements lock
  -> baseline audit
  -> calibration slice
  -> stratified backfill
  -> claim ledger
  -> counterevidence pass
  -> validity review
  -> owner synthesis
  -> morning closeout

What Changes Against Meta2.0

Meta2.0 strength:

stable inventory and digest pipeline
Qwen batch mechanics
audit files and coverage numbers

Meta2.0 weakness for this task:

it is mostly a data-prep system
it does not decide which self-interpretations are valid
it does not force counterevidence before synthesis
it does not create an owner-ready answer contract by itself

Meta3.0 improvement:

a run starts with requirements, not with fanout
every output belongs to a phase
every strong claim enters a ledger
every main claim receives a counterevidence pass
final synthesis is blocked until validity is reviewed
morning closeout records actual calls, errors, missing evidence, and the next owner decision

Core Rule

Do not scale a flawed loop.

The first useful Meta3 run is therefore not the biggest possible run. It is the smallest loop that proves:

Meta2.0 sources are measured correctly.
The question set produces structured claims.
Evidence references are concrete.
Counterevidence is not skipped.
The final answer gives Samuel one usable next mental model.

Required Artifacts Per Serious Run

run_manifest.json: what was attempted.
batch_plan.json: what was planned.
baseline_snapshot.json: what source state existed before scale-up.
source_snapshot_manifest.json: frozen local digest input and checksum.
*_workpackets.jsonl: exact prompt packets a future runner would consume.
*_call_ledger.jsonl: one planned ledger entry per workpacket/API call.
calibration_answers.jsonl: small proof before broad execution.
claim_ledger.jsonl: structured claims.
counterevidence_ledger.jsonl: contradictions, weak spots, limits.
*_collection_report.json: response parsing and schema-validation status.
validity_review.md: what is valid, weak, invalid, or missing.
OWNER_SYNTHESIS.md: owner-facing answers.
MORNING_REPORT.md: actual calls, errors, outputs, and next decision.

Failure Labels

Use these labels instead of vague "worked/did not work":

invalid_measurement: artifacts missing, no comparable baseline, bad manifest.
insufficient_coverage: source coverage too low for final synthesis.
weak_evidence: claims exist but references are thin.
counterevidence_missing: claims were not attacked.
owner_not_ready: output is interesting but not usable by Samuel.
ready_for_owner_review: valid enough for Samuel to inspect.

Morning Question

The next morning, do not ask "Did it run?"

Ask:

Which claims survived evidence, counterevidence, and owner-readiness?