Extraction & verification

This is the heart of Soil · the part everything else exists to serve. The free manual template (anyone can copy a prompt) is the giveaway. The magic is doing this smartly and honestly: better than a generic "summarise this," graded at save time, and · on project loads · measured to actually work when loaded in a different model.

Extraction is agent-assisted, not scraped

A Remote MCP server cannot read your chat history · only the AI already in the conversation can. So Soil doesn't scrape. It directs the model that's already in the room to do the extraction, against a Soil-authored recipe, then checks the result against its own gates. Three beats, all behind the single soil save command:

1. recipe · Soil hands the active AI the extraction schema + the extraction prompt: what sections, what depth, what to include, and what to never include. The recipe also lists a few situational working-style questions the model answers as part of the save · recorded raw, never scored. The active AI is the extractor. (Internally this is the soil_prepare tool step; the model calls it automatically · you never type it.)
2. extract · the active AI fills the schema from the live conversation.
3. verify · Soil validates the filled schema (safety + completeness + provenance), runs the drift check, stores only a safe projection, and returns quality signals.

Soil doesn't trust a single pass

A single extraction is unverified · exactly what a generic prompt gives you, and exactly what Soil has to beat. So the save is a verify-then-gate step, and over MCP it runs turn by turn: each save call is one turn of the loop.

1. Safety scan · Soil sanitizes the filled schema first. Anything forbidden (a secret, a raw payload, a private path) is rejected fail-closed with a safe, value-free note of what to fix · never saved.
2. Verify completeness · score the filled schema against the completeness target. Soil computes a confidence, missing inputs (what's absent or thin), contradictions (internal conflicts), outside-context assumptions (anything that points to a repo, docs, or a link the cold reader will not have · it must be inlined, not referenced), unsafe omissions (what safety forced out that the reader still needs to know about), and a readiness band: Strong or Needs work. Any missing input, contradiction, or outside-context assumption → "Needs work · missing: …" with the exact gaps and targeted re-extraction instructions, not saved.
3. Re-extract the gaps · on a follow-up call the active AI addresses the specific shortfalls Soil named · "fill exactly these holes / resolve exactly this conflict," not "redo it" · and saves again. Each call re-scores; the loop closes when the gaps are gone.
4. Drift check · Soil asks the hard question directly: "could a cold model, given only this handover, continue this project?" For a clean, complete handover whose restore prompt and next steps are substantive, Soil makes this assessment server-side and saves in the same call. A borderline handover instead comes back for a drift-check pass: the model re-reads it cold, fixes what a fresh reader would have to guess, then saves again and confirms the re-read. Soil takes that confirmation at the model's word, and the receipt says so: a pass earned this way is shown as model-reported, never as an independently run test.
5. Save at Strong · a handover is persisted as real only when readiness is Strong, no missing inputs remain (or only safety-justified ones), no unresolved contradictions, the drift check passed, and safety is clean. A complete, high-confidence extraction passes and is saved in one call; only a borderline one needs an extra pass.

When a save is refused

A save either stores a handover or it does not. There is no partial save, and nothing Soil holds along the way ever quietly becomes one. When Soil refuses:

• Nothing is stored. No handover, no load code, no entry in soil list. The receipt leads with that in as many words.
• The refusal names the field. It stays value-free · it never echoes a secret back at you · but it is specific: the section that is over its ceiling, the exact missing inputs and contradictions, the unknown field, the safety descriptor to remove.
• The correction costs one field, not the whole save. For a too long, invalid, gaps, or drift refusal, Soil holds what that attempt carried and hands the model a one-time handle. The next save presents the handle plus only the corrected fields; everything else is inherited byte-identically, and the entire chain · safety scan, bounds, self-containment, completeness, drift gate, project knowledge, plan ceiling · re-runs from scratch on the merged result. That matters because a save lands at the end of a saturated thread, which is the worst possible place to be told "send all of it again."
• The held attempt is not a handover. It is account-scoped, has no load code, appears on no list or load surface, can be used once, and expires after 15 minutes.

Two kinds of refusal deliberately get no cheap retry, and say so:

• Unsafe content. When the safety scan is what refused, nothing is held · holding it would persist the very material the refusal exists to keep out. That retry resends in full, without the value.
• Not a field problem at all. The Free storage ceiling, a @project you are not a member of, an unusable #name, a store fault. No edit to a field clears any of these, so nothing is held and the refusal points at the real fix instead of promising a retry that cannot succeed.

Proving it works across models

Verifying that a handover reads well is not the same as proving it works when loaded in a different model. The unit of truth is the round-trip: produce a handover in one model, start a cold session in another with only that handover, ask it to continue, and check the continuation for drift. The handover "works" only if the second model continues without drift, not if the first wrote it nicely.

That round-trip runs on your own two models · the one you save from and the one you load into. At save time, the from-model writes the answer key while it still has full context; at load time, the to-model answers cold; Soil scores the answers deterministically · pass, unknown, or wrong. The key is not all softballs: some questions deliberately assume an old, changed decision is still true, and the loading model passes only by correcting it · so a summary-parrot fails where a real continuation succeeds. This measurement runs today on project loads (soil load @project); there, the quality of your handover is measured, not claimed. This is covered in plain language in how Soil verifies a handover.

Separately, and never in your sessions, Soil also runs an internal benchmark of the same round-trip across a matrix of save-model × load-model spanning providers, including the adversarial direction (saved by one vendor, loaded by a competitor's). It exists only to validate the method and tune the extraction recipes for everyone. Drift-rate and block-rate are tracked metrics, not vibes.

Why this is the whole point

Everything else · the OAuth bridge, the dashboard, Desktop, the Gateway · is plumbing that delivers this. And the verification loop's real job is to let Soil say "Needs work" honestly. A handover Soil can't grade as ready is never dressed up as one. That refusal to overclaim is the product.