| # 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 |
|
|
| ```text |
| 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: |
|
|
| 1. Meta2.0 sources are measured correctly. |
| 2. The question set produces structured claims. |
| 3. Evidence references are concrete. |
| 4. Counterevidence is not skipped. |
| 5. 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? |
|
|
