modelrig 0.8.0 → 0.9.0

package/screen.d.ts

@@ -0,0 +1,16 @@
+/**
+ * Root type shim for the `modelrig/screen` sub-path export (IP-2a-1).
+ *
+ * Same mechanism as `receipts.d.ts` (RP-1): package.json `exports` points
+ * `modelrig/screen` at `dist/screen/index` for runtime and modern-resolution
+ * TypeScript consumers; classic `moduleResolution: "Node"` consumers —
+ * including this monorepo's `modelrig-server`, whose grader assembly reuses
+ * the SC-0 provenance seam and the SC-1 pattern detector — ignore `exports`
+ * and resolve the bare subpath against the package root, so this file is what
+ * they type-resolve. Both paths land on the same declarations.
+ *
+ * The screen surface stays deliberately OUT of the bare `modelrig` entry
+ * (src/index.ts) — this shim widens nothing there; it only makes the existing
+ * screen module addressable as a sub-path, the way `modelrig/receipts` is.
+ */
+export * from "./dist/screen/index";

package/templates/call-disposition-qa.json

@@ -0,0 +1,77 @@
+{
+  "use_case": "call-disposition-qa",
+  "title": "Call disposition QA",
+  "summary": "From a call transcript, check the disposition the agent logged and score the call against your QA scorecard, handing off the disputed ones to a supervisor.",
+  "fit_note": "Call disposition QA fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) Your dispositions and scorecard are stable enough that last month's calls still describe this month's — if you are still redrawing the scorecard, settle it before you calibrate. (2) Your QA team can write down what a correct disposition and a correct score are, which is the grading guide below. (3) An experienced QA reviewer can grade a batch of past calls against the calls they would have scored, so a grader can be calibrated against them. (4) You handle enough calls that calibration and optimization pay back. This template assumes the call arrives as text: ModelRig takes a transcript as input, so you bring your own transcription upstream and feed the transcript here — the template does not read audio. It gives you a disposition shell and a scorecard-shaped guide to fill in; it makes no claim about how well any model scores a call — that is what your goldens and grades measure.",
+  "starter_schema": {
+    "$schema": "http://json-schema.org/draft-07/schema#",
+    "$comment": "STARTER SCHEMA. Replace every TODO with your own dispositions and scorecard before use. The template runs as-is: free-text fields validate immediately. TODO markers show where adding your own enum values tightens grading to your process; do not copy example words from the docs.",
+    "title": "CallDispositionQa",
+    "type": "object",
+    "additionalProperties": false,
+    "required": ["disposition", "needs_human"],
+    "properties": {
+      "disposition": {
+        "type": "string",
+        "description": "The disposition the transcript actually supports for this call. TODO(enum): constrain this to YOUR own disposition labels by adding an \"enum\": [ ... ] here. It runs as free text immediately; add your own enum values here to tighten validation and grading to your process.",
+        "$comment": "TODO(enum): add your call dispositions as the enum for this field."
+      },
+      "scorecard": {
+        "type": "object",
+        "description": "The QA scorecard result. TODO: replace this placeholder with one named property per item on YOUR scorecard (e.g. verified_identity, disclosed_recording, resolved_issue), each with its own type and description. Keep additionalProperties false once you have listed them so nothing extra is invented.",
+        "additionalProperties": true,
+        "$comment": "TODO(fields): replace with your real scorecard items; add a required list once you know which items must always be present."
+      },
+      "matches_agent_log": {
+        "type": "boolean",
+        "description": "True when the disposition the transcript supports matches the one the agent logged. Lets you surface logged-versus-actual mismatches. Optional; delete it if you do not track the agent's own log."
+      },
+      "needs_human": {
+        "type": "boolean",
+        "description": "True when the call is disputed, sensitive, or the transcript is too incomplete to score confidently and a supervisor should review. Pairs with the escalation band in the grading guide."
+      }
+    }
+  },
+  "starter_guide": {
+    "criteria": [
+      {
+        "id": "disposition-correct",
+        "title": "Disposition matches the call",
+        "pass": "the disposition is the one your QA team would assign given what the transcript shows happened on the call.",
+        "fail": "The disposition does not match the call — a resolved outcome on a call that escalated, or the reverse."
+      },
+      {
+        "id": "grounded-in-transcript",
+        "title": "Every judgment is grounded in the transcript",
+        "pass": "each scorecard result cites something actually said on the call; nothing is inferred beyond the transcript.",
+        "fail": "The output asserts an event, a phrase, or an outcome that the transcript does not contain."
+      },
+      {
+        "id": "scorecard-applied-consistently",
+        "title": "Scorecard is applied by your rules",
+        "pass": "each scorecard item is judged the way your rubric defines it, not by a general impression of the call.",
+        "fail": "A scorecard item is marked pass or fail in a way your own rubric would not, or is skipped when it applies."
+      },
+      {
+        "id": "human-flag-when-unsure",
+        "title": "Disputed or sensitive calls are flagged for a human",
+        "pass": "a call that is disputed, compliance-sensitive, or has a partial or unclear transcript sets needs_human rather than being auto-scored.",
+        "fail": "A call a supervisor would have reviewed is scored automatically with false confidence."
+      }
+    ],
+    "teach_grade_ids": [],
+    "escalation": {
+      "epsilon": 0.1
+    }
+  },
+  "golden_checklist": [
+    "One clear example per disposition in your process — the ordinary, unambiguous call for each outcome.",
+    "A call that could plausibly take two dispositions — the golden fixes which one wins and why.",
+    "A call where the agent's logged disposition does not match what the transcript shows — the golden records the mismatch.",
+    "A compliance-sensitive call (a required disclosure, a dispute, a vulnerable caller) that should reach a supervisor regardless of score.",
+    "A clean, by-the-book call — so the guide learns the ordinary pass, not only the failures.",
+    "An edge case: a partial, cut-off, or garbled transcript — the golden shows it flagged for a human rather than scored as if complete.",
+    "Aim for roughly twenty goldens total, weighted toward the disputed, mismatched, and sensitive calls rather than the clean centre."
+  ],
+  "escalation_starter": "Start by escalating to a supervisor whenever the model sets needs_human, and always for compliance-sensitive calls regardless of the score. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and sent to the supervisor queue. The 0.1 here is a starting band — keep it wide until an experienced reviewer has graded enough calls to trust the grader, then narrow it."
+}

package/templates/catalog-cleansing.json

@@ -0,0 +1,77 @@
+{
+  "use_case": "catalog-cleansing",
+  "title": "Catalog cleansing",
+  "summary": "Normalize a product-catalog record into your own taxonomy and attribute shape, correct what is clearly wrong, and flag the ones a person should check.",
+  "fit_note": "Catalog cleansing fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) Your catalog taxonomy and attribute set are stable enough that a rule that cleaned last month's records still cleans this month's — if the taxonomy is still being redrawn, settle it before you calibrate. (2) Someone who owns the catalog can write down what a correctly cleansed record is, field by field, which is the grading guide below. (3) You have corrected records on hand — rows a person already fixed — so a grader can be calibrated against that ground truth. (4) You process enough records that calibration and optimization pay back. Cleansing usually runs as a batch over a backlog of raw records rather than one at a time; the loop still applies — you grade a representative sample of the batch and let the grades stand in for the rest. This template gives you a taxonomy shell and a grading guide to fill in; it does not assume your fields, and it makes no claim about how well any model cleanses a record — that is what your goldens and grades measure.",
+  "starter_schema": {
+    "$schema": "http://json-schema.org/draft-07/schema#",
+    "$comment": "STARTER SCHEMA. Replace every TODO with your own taxonomy and attributes before use. The template runs as-is: free-text fields validate immediately. TODO markers show where adding your own enum values tightens grading to your catalog; do not copy example words from the docs.",
+    "title": "CatalogCleansing",
+    "type": "object",
+    "additionalProperties": false,
+    "required": ["category", "needs_human"],
+    "properties": {
+      "category": {
+        "type": "string",
+        "description": "The catalog category this record belongs in. TODO(enum): constrain this to YOUR own category labels by adding an \"enum\": [ ... ] here. It runs as free text immediately; add your own enum values here to tighten validation and grading to your taxonomy.",
+        "$comment": "TODO(enum): add your catalog categories as the enum for this field."
+      },
+      "corrected_attributes": {
+        "type": "object",
+        "description": "The cleansed attribute values. TODO: replace this placeholder with one named property per attribute you normalize (e.g. brand, unit_size, color), each with its own type and description. Keep additionalProperties false once you have listed them so nothing extra is invented.",
+        "additionalProperties": true,
+        "$comment": "TODO(fields): replace with your real attribute set; add a required list once you know which attributes must always be present."
+      },
+      "duplicate_of": {
+        "type": "string",
+        "description": "The id of an existing record this one appears to duplicate, when you run dedupe. Leave absent when the record is not a suspected duplicate; the model should flag a suspected merge, never perform it."
+      },
+      "needs_human": {
+        "type": "boolean",
+        "description": "True when the record is too ambiguous or conflicting to cleanse confidently and a person should review. Pairs with the escalation band in the grading guide."
+      }
+    }
+  },
+  "starter_guide": {
+    "criteria": [
+      {
+        "id": "category-correct",
+        "title": "Category is correct",
+        "pass": "the record is placed in the category a person who owns your catalog would have chosen for it.",
+        "fail": "The record is placed in a category that does not match what it actually is, or in a catch-all when a specific category fits."
+      },
+      {
+        "id": "corrections-grounded",
+        "title": "Corrections are grounded in the record",
+        "pass": "every corrected attribute is supported by what the record actually contains, normalized to your format; nothing is invented.",
+        "fail": "A corrected value contradicts the record, or an attribute is filled with a plausible-looking value the record does not support."
+      },
+      {
+        "id": "preserves-correct-data",
+        "title": "Already-correct data is preserved",
+        "pass": "an attribute that was already correct is left intact, not overwritten or dropped.",
+        "fail": "The output alters or removes a field that was already valid, losing data that did not need cleansing."
+      },
+      {
+        "id": "human-flag-when-unsure",
+        "title": "Ambiguous or conflicting records are flagged for a human",
+        "pass": "a record with conflicting attributes, an unrecognizable category, or an uncertain duplicate match sets needs_human rather than being force-cleansed.",
+        "fail": "A record a person would have paused on is cleansed with false confidence, or a suspected duplicate is merged instead of flagged."
+      }
+    ],
+    "teach_grade_ids": [],
+    "escalation": {
+      "epsilon": 0.1
+    }
+  },
+  "golden_checklist": [
+    "One clean example per category in your taxonomy — the ordinary, well-formed record for each category.",
+    "A record that is already correct — the golden shows it left untouched, so the guide learns not to over-correct.",
+    "The two or three categories your catalog most often confuses, side by side, so the guide learns the boundary.",
+    "A record with a conflicting or contradictory attribute — the golden fixes which value is right and why.",
+    "A near-duplicate pair — the golden shows the duplicate flagged for review, not silently merged.",
+    "An edge case: a garbled, truncated, or unrecognizable record — the golden shows it flagged for a human rather than force-cleansed.",
+    "Aim for roughly twenty goldens total, weighted toward the conflicting, duplicate, and already-clean records rather than the easy centre."
+  ],
+  "escalation_starter": "Start by escalating to a person whenever the model sets needs_human, and whenever a suggested duplicate merge would combine records that a person has not confirmed. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and sent to the review queue. The 0.1 here is a starting band — widen it while you build trust on a fresh batch, narrow it as your grader calibrates against your corrected records."
+}

package/templates/compliance-review.json

@@ -0,0 +1,76 @@
+{
+  "use_case": "compliance-review",
+  "title": "Compliance review",
+  "summary": "Check a document or message against your own policy, mark which of your rules it implicates, and send the uncertain and adverse ones to a human reviewer.",
+  "fit_note": "Compliance review fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) Your policy and the material you review are stable enough that last quarter's examples still describe this quarter's — if your rules change constantly, a golden set goes stale, so pin the version you review against. (2) Your compliance or legal team can write down what a correct determination is, rule by rule, which is the grading guide below. (3) A reviewer who knows the policy can grade a batch of past items against the calls they would have made, so a grader can be calibrated against them. (4) You review enough items that calibration and optimization pay back. This template is a first-pass triage that routes work to your reviewers, never a substitute for them: it makes no claim to be a compliance control, and every adverse or uncertain call is meant to reach a person. Fill in your own determinations and rule set before you rely on it.",
+  "starter_schema": {
+    "$schema": "http://json-schema.org/draft-07/schema#",
+    "$comment": "STARTER SCHEMA. Replace every TODO with your own policy before use. The template runs as-is: free-text fields validate immediately. TODO markers show where adding your own enum values tightens grading to your review outcomes; do not copy example words from the docs.",
+    "title": "ComplianceReview",
+    "type": "object",
+    "additionalProperties": false,
+    "required": ["determination", "needs_human"],
+    "properties": {
+      "determination": {
+        "type": "string",
+        "description": "The review outcome for this item. TODO(enum): constrain this to YOUR own outcomes by adding an \"enum\": [ ... ] here (whatever labels your team already uses). It runs as free text immediately; add your own enum values here to tighten validation and grading to your process.",
+        "$comment": "TODO(enum): add your review outcomes as the enum for this field."
+      },
+      "implicated_rules": {
+        "type": "array",
+        "items": { "type": "string" },
+        "description": "The ids or names of the rules in YOUR policy that this item implicates. Leave empty when nothing is implicated. Lets the grader check that a flag cites a rule that actually applies rather than a general impression."
+      },
+      "needs_human": {
+        "type": "boolean",
+        "description": "True when the item is ambiguous, borderline, or adverse and a reviewer should decide. Pairs with the escalation band in the grading guide."
+      },
+      "rationale": {
+        "type": "string",
+        "description": "One or two sentences grounding the determination in the item's own text and the rule it cites. Optional; keep it if you want the grader to check the call is explained."
+      }
+    }
+  },
+  "starter_guide": {
+    "criteria": [
+      {
+        "id": "determination-correct",
+        "title": "Determination is correct",
+        "pass": "the item gets the determination a reviewer on your team would have reached under your policy.",
+        "fail": "The determination is wrong for the item — a clear violation passed, or a clean item marked adverse."
+      },
+      {
+        "id": "rule-actually-applies",
+        "title": "Cited rules actually apply",
+        "pass": "every rule named in implicated_rules is one the item genuinely engages, and each cited rule exists in your policy.",
+        "fail": "The output cites a rule the item does not implicate, or names a rule that is not in your policy at all."
+      },
+      {
+        "id": "no-missed-violation",
+        "title": "Clear violations are not passed",
+        "pass": "an item that plainly breaks a rule is marked, not waved through.",
+        "fail": "An item that clearly violates a rule in your policy is returned as clean."
+      },
+      {
+        "id": "human-flag-when-unsure",
+        "title": "Ambiguous or adverse items are flagged for a human",
+        "pass": "an item that is borderline, novel, or adverse sets needs_human rather than being auto-cleared or auto-flagged with false confidence.",
+        "fail": "An item a reviewer would have hesitated on is decided automatically instead of being sent to a person."
+      }
+    ],
+    "teach_grade_ids": [],
+    "escalation": {
+      "epsilon": 0.1
+    }
+  },
+  "golden_checklist": [
+    "One clear example per determination in your process — the ordinary, unambiguous item for each outcome.",
+    "One clean example and one clear-violation example per rule you review against, so the guide learns each rule's boundary.",
+    "The two or three rules your team most often argues over, side by side, so the guide learns your house reading.",
+    "A borderline item that could plausibly go either way — the golden shows needs_human set rather than a confident call.",
+    "An item that implicates more than one rule at once — the golden records every rule that applies, not just the first.",
+    "An edge case: an empty, off-topic, or unintelligible item — the golden shows it flagged for a human rather than force-decided.",
+    "Aim for roughly twenty goldens total, weighted toward the borderline and multi-rule items rather than the clear-cut centre."
+  ],
+  "escalation_starter": "Start by escalating to a reviewer whenever the model sets needs_human, and treat every adverse determination as review-bound regardless of confidence — a first-pass triage should raise borderline calls, not resolve them. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and sent to the reviewer queue. The 0.1 here is a starting band — keep it wide, and only narrow it once a reviewer has graded enough items to trust the grader."
+}

package/templates/cs-next-action.json

@@ -0,0 +1,76 @@
+{
+  "use_case": "cs-next-action",
+  "title": "Customer-success next action",
+  "summary": "Recommend the next action a CS team should take on an account, grounded in the account's own signals, and hand off the ones that need a human.",
+  "fit_note": "CS next-action fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) Your accounts and playbooks are stable enough that a recommendation that made sense last quarter still makes sense this quarter. (2) Your CS team can write down what a good next action is for a given account state, which is the grading guide below. (3) An experienced CSM can grade a batch of past recommendations against what actually happened or what they would have done. (4) You manage enough accounts that calibration and optimization pay back. This template gives you an action taxonomy shell and a grading guide to fill in. It makes no claim that a model should decide account strategy — it is a starting point for turning your playbook into a graded, improvable route, with a human on the accounts that matter.",
+  "starter_schema": {
+    "$schema": "http://json-schema.org/draft-07/schema#",
+    "$comment": "STARTER SCHEMA. Replace every TODO with your own playbook before use. Enum slots ship without values on purpose — add the actions and urgency levels your CS team actually uses.",
+    "title": "CsNextAction",
+    "type": "object",
+    "additionalProperties": false,
+    "required": ["recommended_action", "urgency", "needs_human"],
+    "properties": {
+      "recommended_action": {
+        "type": "string",
+        "description": "The single next action to take on this account. TODO(enum): add an \"enum\": [ ... ] listing YOUR playbook actions (e.g. the plays your team already runs), so the model chooses from your set rather than inventing one.",
+        "$comment": "TODO(enum): add your playbook actions as the enum for this field."
+      },
+      "urgency": {
+        "type": "string",
+        "description": "How soon the action should happen. TODO(enum): add an \"enum\": [ ... ] with YOUR urgency levels.",
+        "$comment": "TODO(enum): add your urgency levels as the enum for this field."
+      },
+      "rationale": {
+        "type": "string",
+        "description": "One or two sentences naming the account signals that motivate the action (usage trend, support load, renewal date, sentiment). The grader checks that the rationale is grounded in real signals."
+      },
+      "needs_human": {
+        "type": "boolean",
+        "description": "True when the account is high-stakes or the signals are ambiguous and a CSM should decide. Pairs with the escalation band in the grading guide."
+      }
+    }
+  },
+  "starter_guide": {
+    "criteria": [
+      {
+        "id": "action-fits-signals",
+        "title": "Action fits the account's signals",
+        "pass": "the recommended action is the one your playbook calls for given the account's stage and signals.",
+        "fail": "The action does not match the account state — a renewal push at onboarding, a nurture play on an account that is actively churning."
+      },
+      {
+        "id": "grounded-rationale",
+        "title": "Rationale cites real signals",
+        "pass": "The rationale names specific signals present in the account data rather than generic advice that would fit any account.",
+        "fail": "The rationale is boilerplate, or cites a signal the account data does not contain."
+      },
+      {
+        "id": "stays-in-remit",
+        "title": "Recommendation stays within CS remit",
+        "pass": "the action is something CS can actually do; it does not commit pricing, contract terms, or promises outside the team's authority.",
+        "fail": "The action oversteps — promising a discount, a roadmap commitment, or anything that needs another team's sign-off."
+      },
+      {
+        "id": "safe-default-when-unsure",
+        "title": "Ambiguous accounts get a safe default or a human",
+        "pass": "when the signals are thin or conflicting, the recommendation is a low-risk action or needs_human, not a confident high-stakes move.",
+        "fail": "A high-stakes action is recommended on an account whose signals do not support it."
+      }
+    ],
+    "teach_grade_ids": [],
+    "escalation": {
+      "epsilon": 0.1
+    }
+  },
+  "golden_checklist": [
+    "One clear example per action in your playbook — the account state where that action is plainly right.",
+    "The two or three account states your team most often disagrees on, so the guide learns your house rules.",
+    "A high-value or at-risk account where the safe move is to hand off to a human — the golden shows needs_human set.",
+    "A brand-new account with almost no signal yet — the golden shows a low-risk default rather than a confident play.",
+    "An account whose signals point two ways (growing usage but falling sentiment) — the golden fixes which signal wins.",
+    "A case where a tempting action would overstep CS remit — the golden shows it declined in favour of an in-remit action.",
+    "Aim for roughly twenty goldens total, weighted toward the ambiguous and high-stakes accounts rather than the easy ones."
+  ],
+  "escalation_starter": "Start by escalating to a human whenever the model sets needs_human, and always for your highest-value or clearly at-risk accounts regardless of the recommended action. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and routed to a CSM. The 0.1 here is a starting band — keep it wide until an experienced CSM has graded enough recommendations to trust the grader, then narrow it."
+}

package/templates/document-extraction.json

@@ -0,0 +1,78 @@
+{
+  "use_case": "document-extraction",
+  "title": "Document extraction",
+  "summary": "Pull the fields you care about out of a document (an invoice, a form, a contract clause) into a structured object your code can use.",
+  "fit_note": "Document extraction fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) The documents you extract from are stable in kind — the same layouts and field set recur, so past examples still describe new ones. (2) Someone can write down what a correct extraction is field by field, which is the grading guide below. (3) You have corrected extractions on hand — records where a person already fixed the fields — so a grader can be calibrated against ground truth. (4) You process enough documents that calibration and optimization pay back. This template gives you a schema shell and a grading guide to fill in; it does not assume your fields, and it makes no claim about how well any model extracts them — that is what your goldens and grades measure.",
+  "starter_schema": {
+    "$schema": "http://json-schema.org/draft-07/schema#",
+    "$comment": "STARTER SCHEMA. The fields below are placeholders. Replace them with the fields YOU extract, delete the ones you do not need, and mark each field required or optional to match your documents.",
+    "title": "DocumentExtraction",
+    "type": "object",
+    "additionalProperties": false,
+    "required": [],
+    "properties": {
+      "document_type": {
+        "type": "string",
+        "description": "What kind of document this is. TODO(enum): add an \"enum\": [ ... ] listing the document types you handle, so the model cannot invent a type.",
+        "$comment": "TODO(enum): add your document types as the enum for this field."
+      },
+      "fields": {
+        "type": "object",
+        "description": "The extracted values. TODO: replace this placeholder with one named property per field you extract (e.g. invoice_number, total_amount, issue_date), each with its own type and description. Keep additionalProperties false once you have listed them so nothing extra is invented.",
+        "additionalProperties": true,
+        "$comment": "TODO(fields): replace with your real field set; add a required list once you know which fields must always be present."
+      },
+      "missing_fields": {
+        "type": "array",
+        "items": { "type": "string" },
+        "description": "Names of fields you asked for that were genuinely absent from the document. Lets the model say \"not present\" explicitly instead of guessing a value."
+      },
+      "needs_human": {
+        "type": "boolean",
+        "description": "True when the document is too unclear to extract confidently and a person should review. Pairs with the escalation band in the grading guide."
+      }
+    }
+  },
+  "starter_guide": {
+    "criteria": [
+      {
+        "id": "values-match-source",
+        "title": "Extracted values match the document",
+        "pass": "every extracted value is exactly what the document says, in the format you asked for.",
+        "fail": "A value differs from the document — a wrong number, a transcription slip, a mis-parsed date."
+      },
+      {
+        "id": "no-fabrication",
+        "title": "Absent fields are marked, never invented",
+        "pass": "A field that is not in the document is reported as missing rather than filled with a plausible-looking value.",
+        "fail": "The output supplies a value for a field the document does not actually contain."
+      },
+      {
+        "id": "completeness",
+        "title": "Present fields are all captured",
+        "pass": "every field that IS in the document and IS in your schema is extracted; none is silently dropped.",
+        "fail": "A field that is clearly present in the document is left out of the output."
+      },
+      {
+        "id": "human-flag-when-illegible",
+        "title": "Unreadable documents are flagged for a human",
+        "pass": "A document that is illegible, truncated, or the wrong kind sets needs_human rather than returning a confident-looking but unreliable extraction.",
+        "fail": "An unreadable or off-type document is extracted as if it were clean."
+      }
+    ],
+    "teach_grade_ids": [],
+    "escalation": {
+      "epsilon": 0.1
+    }
+  },
+  "golden_checklist": [
+    "One clean example per document type in your set — the ordinary, fully-legible case for each layout.",
+    "A document that is missing one or more of your fields — the golden shows those fields reported as missing, not invented.",
+    "A document with a field in an unusual but valid format (a date written differently, a total with a currency symbol) so the guide learns your normalization rules.",
+    "A multi-page or multi-section document where the field you want appears late or twice — the golden fixes which occurrence is correct.",
+    "An ambiguous or partially-legible document — the golden shows it flagged for a human rather than guessed.",
+    "An off-type document (something that is not one of your document types at all) — the golden shows it rejected or flagged, not force-extracted.",
+    "Aim for roughly twenty goldens total, weighted toward missing fields, odd formats, and illegible cases rather than the clean centre."
+  ],
+  "escalation_starter": "Start by escalating to a human whenever the model sets needs_human, and whenever a required field comes back missing on a document that should contain it. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and sent to the human queue. The 0.1 here is a starting band — widen it early, narrow it as your grader calibrates against your corrected extractions."
+}

package/templates/financial-classification.json

@@ -0,0 +1,75 @@
+{
+  "use_case": "financial-classification",
+  "title": "Financial classification",
+  "summary": "Classify a financial record — a transaction, a document, a case — into your own categories and risk flags, and hand off the ones a person must review.",
+  "fit_note": "Financial classification fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) Your categories and the records you classify are stable enough that last quarter's examples still describe this quarter's — if the taxonomy is still moving, settle it before you calibrate. (2) Someone who owns the process can write down what a correct classification is, which is the grading guide below. (3) A reviewer who knows the domain can grade a batch of past records against the calls they would have made, so a grader can be calibrated against them. (4) You process enough records that calibration and optimization pay back. Financial records are regulated data, so the custody terms come first — quoted verbatim from the published content custody terms: \"Do not send protected health information or other regulated data through ModelRig until a BAA or DPA is in place. This service is not offered for regulated data today, and nothing on this page should be read as agreeing to handle it.\" Until those terms are in place, the today-path is to run this on a zero-retention route (or with content custody turned off), so ModelRig holds no content and grading is limited to the scores and metadata your own systems send. The full terms are at https://modelrig.ai/terms/content-custody. This template gives you a classification shell and a grading guide to fill in; it makes no claim about how well any model classifies your records — that is what your goldens and grades measure — and it makes no compliance claim of any other kind.",
+  "starter_schema": {
+    "$schema": "http://json-schema.org/draft-07/schema#",
+    "$comment": "STARTER SCHEMA. Replace every TODO with your own taxonomy before use. The template runs as-is: free-text fields validate immediately. TODO markers show where adding your own enum values tightens grading to your categories; do not copy example words from the docs.",
+    "title": "FinancialClassification",
+    "type": "object",
+    "additionalProperties": false,
+    "required": ["classification", "needs_human"],
+    "properties": {
+      "classification": {
+        "type": "string",
+        "description": "The category this financial record belongs in. TODO(enum): constrain this to YOUR own category labels by adding an \"enum\": [ ... ] here. It runs as free text immediately; add your own enum values here to tighten validation and grading to your taxonomy.",
+        "$comment": "TODO(enum): add your financial categories as the enum for this field."
+      },
+      "risk_flag": {
+        "type": "boolean",
+        "description": "True when the record carries a risk your process wants surfaced (a review trigger, an exception, a regulatory-sensitive case). Optional; delete it if you do not track a risk flag."
+      },
+      "needs_human": {
+        "type": "boolean",
+        "description": "True when the record is ambiguous or regulatory-sensitive and a person must decide. Pairs with the escalation band in the grading guide."
+      },
+      "rationale": {
+        "type": "string",
+        "description": "One or two sentences grounding the classification in what the record actually contains. Optional; keep it if you want the grader to check the decision is explained."
+      }
+    }
+  },
+  "starter_guide": {
+    "criteria": [
+      {
+        "id": "classification-correct",
+        "title": "Classification is correct",
+        "pass": "the record gets the category a reviewer on your team would have chosen for it, by your own rules.",
+        "fail": "The record is classified into a category that does not match what it actually is, or into a catch-all when a specific category fits."
+      },
+      {
+        "id": "grounded-no-invention",
+        "title": "Decision is grounded in the record",
+        "pass": "every part of the classification is supported by something the record actually contains; nothing is invented.",
+        "fail": "The output asserts an amount, a party, or a status that the record does not contain."
+      },
+      {
+        "id": "risk-consistent-with-rules",
+        "title": "Risk flag follows your rules",
+        "pass": "the risk flag is set when your own criteria call for it and clear when they do not.",
+        "fail": "A record your rules would flag is left unflagged, or a routine record is flagged for a risk it does not carry."
+      },
+      {
+        "id": "human-flag-when-unsure",
+        "title": "Ambiguous or sensitive records are flagged for a human",
+        "pass": "a record that is genuinely ambiguous or regulatory-sensitive sets needs_human rather than being auto-classified.",
+        "fail": "A record a reviewer would have hesitated on is classified automatically with false confidence."
+      }
+    ],
+    "teach_grade_ids": [],
+    "escalation": {
+      "epsilon": 0.1
+    }
+  },
+  "golden_checklist": [
+    "One clear example per category in your taxonomy — the ordinary, unambiguous record for each category.",
+    "The two or three categories your team most often confuses, side by side, so the guide learns the boundary between them.",
+    "A record that sits on the edge of a risk rule — the golden fixes whether it is flagged and why.",
+    "A regulatory-sensitive record that should reach a person regardless of category — the golden shows needs_human set.",
+    "An incomplete or malformed record — the golden shows it flagged for a human rather than force-classified.",
+    "A routine, low-risk record — so the guide learns the ordinary pass, not only the exceptions.",
+    "Aim for roughly twenty goldens total, weighted toward the edge-of-rule and sensitive records rather than the routine centre."
+  ],
+  "escalation_starter": "Start by escalating to a person whenever the model sets needs_human, and always for regulatory-sensitive or high-risk records regardless of the classification. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and sent to the review queue. The 0.1 here is a starting band — keep it wide until a reviewer has graded enough records to trust the grader, then narrow it."
+}

package/templates/lead-qualification.json

@@ -0,0 +1,76 @@
+{
+  "use_case": "lead-qualification",
+  "title": "Lead qualification",
+  "summary": "Sort an inbound lead into your own qualification stages and a routing segment, and flag the ones a person should work by hand.",
+  "fit_note": "Lead qualification fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) Your idea of a qualified lead is stable enough that the leads that qualified last quarter still describe the ones arriving now — if your ideal-customer profile is still moving, settle it before you calibrate. (2) Your sales team can write down what a correct qualification decision is, which is the grading guide below. (3) An experienced rep can grade a batch of past leads against what actually closed or what they would have decided, so a grader can be calibrated against them. (4) You take in enough leads that calibration and optimization pay back. This template gives you a qualification-stage shell and a grading guide to fill in; it does not assume your stages, and it makes no claim about how well any model qualifies a lead — that is what your goldens and grades measure.",
+  "starter_schema": {
+    "$schema": "http://json-schema.org/draft-07/schema#",
+    "$comment": "STARTER SCHEMA. Replace every TODO with your own funnel before use. The template runs as-is: free-text fields validate immediately. TODO markers show where adding your own enum values tightens grading to your stages and segments; do not copy example words from the docs.",
+    "title": "LeadQualification",
+    "type": "object",
+    "additionalProperties": false,
+    "required": ["qualification", "needs_human"],
+    "properties": {
+      "qualification": {
+        "type": "string",
+        "description": "Which qualification stage the lead belongs in. TODO(enum): constrain this to YOUR own stage labels by adding an \"enum\": [ ... ] here. It runs as free text immediately; add your own enum values here to tighten validation and grading to your funnel.",
+        "$comment": "TODO(enum): add your qualification stages as the enum for this field."
+      },
+      "segment": {
+        "type": "string",
+        "description": "Which team, region, or product the lead should route to. TODO(enum): add an \"enum\": [ ... ] with YOUR routing segments. Optional — delete it if you route by a single rule.",
+        "$comment": "TODO(enum): add your routing segments as the enum for this field."
+      },
+      "needs_human": {
+        "type": "boolean",
+        "description": "True when the model is not confident enough to qualify the lead automatically and a rep should decide. Pairs with the escalation band in the grading guide."
+      },
+      "rationale": {
+        "type": "string",
+        "description": "One short sentence naming the signals in the lead that support the qualification (fit, intent, source, stated need). Optional; keep it if you want the grader to check the decision is grounded."
+      }
+    }
+  },
+  "starter_guide": {
+    "criteria": [
+      {
+        "id": "qualification-correct",
+        "title": "Qualification stage is correct",
+        "pass": "the lead is put in the stage a rep on your team would have chosen for it, by your own qualification rules.",
+        "fail": "The lead is qualified higher or lower than its signals warrant — a cold lead marked sales-ready, or a strong fit left unqualified."
+      },
+      {
+        "id": "grounded-no-invention",
+        "title": "Decision is grounded in the lead",
+        "pass": "every part of the decision is supported by something the lead record actually contains; nothing is invented.",
+        "fail": "The output asserts a firmographic, an intent signal, or a budget that the lead record does not contain."
+      },
+      {
+        "id": "segment-fits-routing",
+        "title": "Segment matches your routing rules",
+        "pass": "the routing segment is the one your rules assign to this lead's region, size, or product interest.",
+        "fail": "The lead is routed to a segment its own attributes do not match, or to a catch-all when a specific segment applies."
+      },
+      {
+        "id": "human-flag-when-unsure",
+        "title": "Ambiguous or high-value leads are flagged for a human",
+        "pass": "a lead that is genuinely ambiguous, thin on signal, or unusually high-value sets needs_human rather than being auto-qualified.",
+        "fail": "A lead a rep would have hesitated on is qualified with false confidence."
+      }
+    ],
+    "teach_grade_ids": [],
+    "escalation": {
+      "epsilon": 0.1
+    }
+  },
+  "golden_checklist": [
+    "One clear example per qualification stage in your funnel — the ordinary, unambiguous lead for each stage.",
+    "The two or three stages your team most often disagrees on, side by side, so the guide learns the boundary between them.",
+    "A lead whose signals point two ways (strong fit but no stated intent, or high intent but a poor fit) — the golden fixes which signal wins.",
+    "A high-value or strategic lead where the safe move is to hand off to a rep — the golden shows needs_human set.",
+    "A thin lead with almost no signal yet — the golden shows a conservative stage rather than a confident qualification.",
+    "An edge case: an empty, spam, or clearly mis-submitted lead — the golden shows it flagged for a human rather than force-qualified.",
+    "Aim for roughly twenty goldens total, weighted toward the ambiguous and high-value leads rather than the easy centre of each stage."
+  ],
+  "escalation_starter": "Start by escalating to a rep whenever the model sets needs_human, and always for your highest-value or strategic leads regardless of the qualification. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and sent to a rep. The 0.1 here is a starting band — keep it wide until an experienced rep has graded enough leads to trust the grader, then narrow it."
+}