AGENTS.md — SAT Math

Digital SAT Mathematics — worked-example fragment.

You are an agent navigating a knowledge tree built by the curious ontology-builder. This file tells you how to read it without wasting the context you have.

This tree: 4 nodes (1 backbone, 1 concept, 2 detail) · 9 edges · source coverage 100% · why-important coverage 100% · 1 open conflict(s) · 1 open gap(s)

Layout

00-MAP.md          the routing file — backbone in prose. Read this first.
AGENTS.md          this file.
01-backbone/       1 node file(s). The load-bearing structure.
02-concepts/       1 node file(s). Where the backbone lands.
03-details/        2 node file(s). Tactics, facts, procedures.
99-provenance/     coverage-map, gap-register, dropped, source-index.
graph.json         the whole tree as data. Query it; do not read it front to back.
run-report.json    how this tree was built (metrics, validator result).

Directories carry no meaning of their own: layer is declared in each node's frontmatter and the directory only has to agree with it. Read layer, knowledge_type and detail_class from the data — never infer from a path.

Navigation law

Your context window is your working schema of this subject. What you load into it, and in what order, IS the schema you end up with — so treat every instruction below as a load-order rule, not a filing convention.

1. Anchors before arrivals

Read 00-MAP.md and the backbone layer before you open anything below it. Attachment structure has to exist before the material meant to attach to it: a detail read without its anchor is an unintegrated fact you will misfile. Concretely: B02 (Linear relationships) is the widest backbone node here and slope-as-rate-of-change (Slope as rate of change) hangs off it, with slope-intercept-form (Slope-intercept form) below that. Establish that spine first; descend into it only afterwards.

2. Descend by children, in importance order

Every node names its parent in chunk and its children in children, pre-computed — descent is a field read, not a search. Because the tree obeys a 2–4 branching rule, any detail is at most three hops from a backbone node.

Descend only in service of a standing question. Never read in directory order, never alphabetically, never front to back: choose the next node by importance to the question you are actually answering. If you cannot say which question a read serves, do not make the read.

Example descent in this tree: B02 → slope-as-rate-of-change → slope-intercept-form.

3. weight and why_important route attention — they never replace reading

relations[].weight runs 5 (load-bearing: the connection the node's meaning depends on) down to 1 (incidental: worth knowing, safe to defer). It is a precision weight: it tells you what to read next and what to hold in context, and it is never the answer itself. The same goes for why_important — it is the stored rationale for a node's rank, not a substitute for the node's statement. Never answer from a weight or a why-important line alone; open the node.

The heaviest edge in this tree is slope-as-rate-of-change --in-context--> slope-from-two-points at weight 5: The two-point computation is how slope is recovered in every item that supplies data rather than an equation;

4. Consolidate and evict every 2–3 nodes

Raw node text held in context is an unintegrated keyword list: high load, low structure. After two or three nodes, stop and consolidate — write down the conclusion each read established, with the node id it came from, then let the raw content go. Evicting the source text is what lets your total reading exceed what one context window could hold. Carry conclusions forward, never transcripts.

5. Guard against false attachment

Your training already contains something that resembles most of this subject. That is the danger, not the help. When a node's claim looks identical to what you already believe, that is precisely when to slow down and check its exact formulation: this tree deviates from standard treatments deliberately, and flattening a deviation into your prior schema destroys the one thing worth capturing. A surprise or a contradiction is the most valuable thing you can find here — read it twice and quote it rather than paraphrasing it.

The inverse failure — nothing to attach to — has its own rule: if a node will not connect to anything you have established, do not push deeper. Go back up to its chunk and rebuild the broader structure first.

6. Read status, gaps and quotability before you rely on a node

status is canonical (use it), scaffold (a deliberate simplification held for beginners — never present it as the final word), stub (thin; say so) or deprecated (never generate from it; follow the supersession edge to its successor). A node listing an open gap is depth-limited: you may still use what it holds, but you may not claim coverage — quote the gap's statement as the honest reason. A node listing an open conflict must not be used to adjudicate; present both claims and their scope. In sources[], quotable: false means surface the node's own statement and why_important, never the source text.

Query recipes

Four ways to use this tree, written against its actual node ids — B02, slope-as-rate-of-change, slope-intercept-form. Run them over graph.json; the markdown files are the human-readable source of truth, graph.json is the queryable derivation of the same content.

Recipe 1 — Diagnostic descent (where is the learner's error?)

Start coarse and descend only where answers falter. Level 0 is every layer: backbone node with status in {canonical, scaffold}; each level down is that node's children.

Ask about B02 first; if the answer is shaky, descend to slope-as-rate-of-change, and only then to slope-intercept-form.

Question level → operand → answer key:

Level	Operand	Graded against
L1 recall	a node, lane: rote preferred	its statement
L2 explain	a node	its procedure if non-null, else statement
L3 relate	a knowledge edge	the edge's rationale + both endpoints' statement
L4 judge importance	a knowledge edge with weight >= 4	the edge's rationale as rubric, both why_important as context

The L4 item this tree supports best is the weight-5 slope-as-rate-of-change → slope-from-two-points edge: ask why that connection matters and grade against its stored rationale.

Honesty rule: report tested N of M, where M excludes depth-limited nodes (open gap, or status: stub). Never silently count a node you could not test.

Recipe 2 — SIR deck (spaced interleaved retrieval)

Lane routing is a field read: lane: rote goes to the flashcard lane, lane: generative to generative recall.

Rote nodes in this tree: slope-intercept-form.

The interleaving unit is the confusability set: same-chunk siblings plus nodes joined by an analogous edge (symmetrise those — they are stored one way but confusability is mutual). Interleave only when the set has 2 or more live members; below that, blocked practice is correct.

Here: slope-as-rate-of-change and unit-rate-word-problems are analogous — "Per one unit" in a word problem is the same quantity students already compute in pricing and speed contexts, which is the cheapest available prior-knowledge hook.

Item shapes: from an edge, prompt with both endpoint names and the edge type, answer key rationale, item id edge.id. From a node, ask why it matters to its chunk, answer key why_important, item id node.id. Exclude any operand that is conflicted or depth-limited.

Recipe 3 — Frontier detection (what to teach next)

The frontier is attachable-but-unknown: nodes not yet in the known set K, with status: canonical (a scaffold is scheduled for replacement — never aim a learner at one), not depth-limited, and adjacent to something in K through a knowledge or structural edge. Attachment runs through the hierarchy as well as through relations, so traverse both kinds; skip warning and supersession.

Worked on this tree: if K = {B02}, then slope-as-rate-of-change is on the frontier — parent edges carry weight 5, so a child of a known chunk is maximally attachable and is what you lead with.

Rank the frontier by leverage — the sum of the weights of the knowledge edges touching a node, plus its child count — and show the learner why_important as the reason it ranks where it does. A node with no knowledge edges and no children has no anchor at all: route to its chunk and build the shallower structure first rather than targeting it.

Recipe 4 — Resource mapping (which material answers this?)

Question → material is a lookup, not a retrieval problem. For each operand node, walk its sources[] entries and resolve each (doc, locator) pair against the top-level source_units array.

Example: B02 cites college-board/digital-sat-math-spec-2024 at §2.1/Algebra (capture: verbatim, quotable: True).

Then: drop units whose disposition is dropped or provenance — the tree judged them to carry no mechanism. A unit with disposition: gap is never offered as material; surface its gap id as an honest "this was not covered". Order global before local: sort by operand layer (backbone → concept → detail), then by the unit's position in source_units, which is the source's own sequence.

Release two or three keywords' worth at a time, not the whole list — medium sizes the ask (a video locator is a timestamp range; an item-set locator is one item). If documents[doc].restricted is true, or a source entry has quotable: false, never surface the source text: give the document title plus the node's own statement and why_important. And when grading, read capture: disagreeing with an inferred claim is weaker evidence of a learner error than disagreeing with a verbatim one.

What this tree does not know

1 open gap(s). These are things the sources referenced but the tree does not hold; the nodes that point at them are depth-limited. Named: G007.

1 open conflict(s) — cf-01. The tree holds both claims on purpose. Present the scope and the disagreement; do not adjudicate.

Validator at export: 0 error(s), 3 warning(s) — codes W1, W2, W7.

---

Generated by skemify from this tree's graph.json. Every id, count and rationale above is read out of the tree — if the tree is rebuilt, regenerate this file rather than editing it.