Improving answers

A pack tells you when an answer falls short, and how it falls short tells you what to fix. Fix the side that fell short, then ask again.

The answer…	What it means	Fix
Read a word wrong (the wrong measure, value, or nothing at all)	A misread: the pack has the fact but read the question wrong. Check this first.	Fix the term in the Lexicon.
Says it lacks a definition or fact	A knowledge-miss: the pack doesn’t know something.	teach it.
Can’t find or resolve the data (“no rows”, “couldn’t resolve”)	A data-miss: the data isn’t modeled for this question yet.	task the pack to model it.
Exists, but is slow or from the wrong source	The pack knows it, but isn’t routed to it.	Add a line under # Routing in PACK.md.

ask won’t fabricate an answer to paper over a gap. To see why an answer came out the way it did before you route it, run edisyl action explain <action-id>. Gaps also show up before anyone asks: an objective that calibration grades failing or declined routes the same way.

Misread → the Lexicon

Most wrong answers on a pack whose sources already hold the fact are misreads, and no new document fixes a misread. See which term each word matched:

edisyl pack vocabulary preview "$PACK" "<the failing question>"

A word that matched nothing, or the wrong model, measure, or value, needs a term. Two spellings split across two terms need a merge. See The Lexicon for each edit. If the pack used the wrong source, the wrong period, or the wrong style, fix it in PACK.md instead.

Knowledge-miss → teach

When ask lacks a fact or definition, the fix is more knowledge. Pick the cheapest reliable source for the missing topic:

1. You already know it, or it’s general: draft a short, factual note.
2. Publicly researchable: research it, synthesize a concise note, cite the sources. Or hand it to the pack: edisyl task "$PACK" "research X and add it to the pack".
3. Org-internal or unverifiable: ask whoever owns that knowledge to provide it. Don’t invent it.

Confirm before you write

Never write to a pack without confirming first: a wrong page poisons every future answer. Show the draft and the payoff, then wait for a yes: “Adding a note on X would make ‘<the question>’ answerable. Here’s the draft. Want me to add it?”

Only on confirmation:

edisyl teach "$PACK" --text "<the note>"       # or --file <path>
edisyl action watch <action-id>                # wait until indexed
edisyl ask "$PACK" "<the failing question>" --wait   # re-ask

The re-ask can still come back with a missing-source gap until the new document is compiled into the pack, which can take tens of minutes for a large one. Check edisyl calibrate status "$PACK", wait, and ask again rather than teaching the same document twice or handing it to task.

Data-miss → task the pack to curate

When ask can’t find or resolve modeled data, hand the pack the work in plain language. A task runs one agent over the pack: it answers the questions the objective raises through ask, models tables, enriches the semantic layer so the next ask lands, and hands bulky or independent work out to subtasks.

action_id=$(edisyl task "$PACK" "The 'active wallets' question failed to resolve — model the wallet/swap tables so it answers." --id-only)
edisyl action watch "$action_id"      # narrates what the task is doing as it moves
edisyl action events <action-id>      # raw event tail, when you need to diagnose
edisyl action get <action-id>         # summary + artifacts once terminal
edisyl ask "$PACK" "<the failing question>" --wait   # re-ask — it should land now

When you already know which tables the question needs and what about them matters, study those tables directly with guidance instead:

edisyl data-sources models <data-source-id>     # find the models' full names
edisyl study "$PACK" <data-source-id> prod.analytics.fact_swaps \
  --guidance "volume is reported in USD at the swap timestamp"

task is also the verb for any broader work: “audit the validator docs and flag anything stale”, “focus enrichment on the DeFi sources”, and a task can itself ask and teach as child Actions.

Use judgment on when to curate

Curate once after connecting a source, and whenever a data-miss ask exposes a real gap. Don’t curate on every question, and don’t curate a knowledge-miss; that’s a teach, not a task.

This loop is reactive by nature: it only routes a gap once an ask exposes it. To declare what a pack must answer before anyone asks, see Objectives, the standing counterpart to this same routing instinct.

Next: Scheduling recurring work turns this same loop into something that runs itself.