Brain - glossary (reusable terms)

glossary

Brain - glossary (reusable terms)

💡 terms defined once and reused across sources, promoted from source LEARNING.md files. Keep each to 1-2 sentences. Cite the source where the term was learned.

Term 💡 Explanation First source
Dynamic Client Registration (DCR) An OAuth extension letting a client register itself with an authorization server at runtime and receive a client ID, with no human filling in a developer-portal form. MCP leaned on it because a client that can talk to any server cannot have been pre-registered with all of them. GitHub evaluated it and declined, on unbounded app-database growth, unbucketable rate limits and absent app identity (claim 222). S27 (n12, n13)
Client ID Metadata Document (CIMD) Identifies an OAuth client by a URL that serves the client's own metadata, so identity is anchored to a domain someone controls rather than self-asserted at registration. The expected successor to DCR in the MCP ecosystem, and unpromised by GitHub. S27 (n13)
Step-up auth Returning a scope challenge mid-call rather than failing, so the user grants the missing scope interactively and the tool call continues. Converts a permission dead end into least privilege that gets more usable as it gets more precise. S27 (n15)
Scope filtering Deriving the tool list a caller sees from the scopes their credential already carries, rather than from anything they configure. The filter is free because it consults a fact the server was going to check anyway (claim 221). S27 (n15)
readOnlyHint An MCP tool annotation declaring that a tool performs no writes. Present in the specification and surfaced as a filter by essentially no client, which is why GitHub ships a redundant read-only mode reaching ~17% of users (claim 225). S27 (n21)
Session affinity Routing a client's requests to the same server instance every time. GitHub's MCP server has none, which is what lets any instance serve any call and is the precondition for per-request tool-list construction. S27 (n16)
Code mode Having the model write code that calls tools, rather than emitting one tool call per turn, so composition happens outside the context window. Cloudflare's approach, named by S27 as one of the shifts expected to make thousands of tools normal. S27 (n19)
Classification report Per-class precision, recall and F1 - the standard scikit-learn output. Applied to tool selection by treating each tool as a class and each request as an instance to label, which turns description tuning into a measurable optimisation instead of a matter of taste (claim 220). S27 (n10) - the source shows the artifact without naming the technique
Lethal trifecta Simon Willison's name for the combination that makes exfiltration possible: access to private data, exposure to untrusted content, and a means of communicating outward. Any two are usually safe and all three are not. S27 (n14)
Corroboration gate The check that keeps a visual's meaning only when the agent's reading of it agrees with the surrounding text. Two-modality agreement is what makes a kept visual trustworthy. (kit design)
Knowledge node The atomic unit of the brain: one corroborated claim + its visual + its text quote + citation + confidence. (kit design)
Valid (in Brain) Corroborated + coherent + on-topic - not fact-checked against reality. The brain surfaces and cites; the human judges truth. (kit design)
pass@k Two sources here use this notation for two different things, and the difference is not cosmetic. S1 means the pass rate at the k-th sequential retry, where each retry folds the QA gate's failure reasoning back into the prompt, so k is a round of a feedback loop. S14 means the field-standard sense: the probability that at least one of k independent samples is correct, with no feedback between them. S1's quantity can only rise because information is being added; S14's rises purely because more lottery tickets were bought. Prefer "coverage" for the S14 sense when both are in play, which is what S14's own slide does. S1 (&t=850s); S14 (n3, &t=2212s)
Coverage Whether at least one of k sampled attempts is correct - the generator's half of the problem, and pass@k in its standard sense. Says nothing about whether the correct sample could actually be found. Almost every overstatement in the self-improvement literature comes from reporting a coverage result as though it were an accuracy result. S14 (n3, n4)
Precision (sampling) Whether a correct solution can be identified among many candidates - the selection half, and where verifiers live. Distinct from coverage because the two fail for unrelated reasons: coverage is bought with compute, precision is bought with a verifier, and no amount of compute manufactures one. S14 (n4)
Generator-verifier gap The distance between what a system can produce and what it can recognise as good. Named in S14 as the field's central obstacle: generation is cheap and scales, recognition is scarce and often needs a human. It is the reason self-improvement runs in code and math and stalls in creative work. S14 (n6)
Oracle verifier A selection step given access to the ground-truth answer. A research instrument for isolating coverage from precision, and by construction not deployable. Seeing it in a benchmark's title means that benchmark's curve assumes the hard half is already solved. S14 (n3)
Test-time (inference) scaling Spending more compute per query - repeated sampling, longer reasoning chains - with the model's weights fixed. Distinct from serving efficiency, which is what topics/inferencing.md covers: this buys accuracy, not throughput. S14 (n1)
Distilling synthetic reasoning traces Filtering many sampled solutions down to the ones that reached a correct answer, then fine-tuning on those traces. The return arrow that closes the self-improvement loop, and the reason the training data costs no human labour. S14 (n5)
Pairwise comparison (evals) Evaluating an edit by comparing output against input (better? faithful? complete? natural? did anything regress?) rather than scoring in isolation; output is yes/no/unsure. S1 (&t=896s)
Swiss-cheese model Stacking several imperfect QA gates so their "holes" rarely line up - deliberate redundancy that stops failures reaching production. S1 (&t=1082s)
Golden dataset A representative, objectively human-labeled truth set an agent is aligned to and benchmarked against. S1 (&t=528s)
Diagnoser (agent) A meta-agent that reads any feedback loop, localizes which sub-agent is failing, and triggers its config auto-tune. S1 (&t=1144s)
Closed-loop eval An eval system that samples production output, re-labels it, diagnoses drift, and auto-tunes the agent config with no human editing prompts. S1 (&t=650s)
12-factor agent Dex Horthy's list of 12 design rules for reliable LLM applications, named after Heroku's 12-factor app. Each factor names a piece of the system you should own rather than delegate to a framework. S2 (&t=141s)
Context engineering The single discipline behind prompt, memory, RAG and history: deciding exactly which tokens reach the model. Treats them as one problem, not four subsystems. S2 (&t=616s)
Micro agent A small agent loop of roughly 3-10 steps embedded at a hard point inside an otherwise deterministic pipeline - the shape that works in production. S2 (&t=741s)
Structured output The model emitting JSON conforming to a schema you defined, rather than prose. The capability all "tool use" actually rests on. S2 (&t=229s)
Materialised DAG The graph of steps an agent loop produces at runtime, as opposed to a DAG written up front in Airflow or Prefect. S2 (&t=371s)
Spin-out (agent) The failure mode where raw errors are blindly appended to the context window until the agent loses the thread and gets stuck retrying. S2 (&t=653s)
Stateless reducer An agent that holds no state of its own, folding each event into a thread you own. Pedantically a transducer, since there are multiple steps. S2 (&t=865s)
Own your control flow Keeping the loop, the switch on model output, the prompt and the context builder in your own code, so you can break, summarise or judge mid-run instead of waiting for a framework to return. S2 (&t=406s)

| Context rot | The measurable decline in LLM output quality as input length grows, independent of task difficulty - not a capacity limit being hit, but a gradient you are already on. Measured across 18 models. | R1 (Chroma, T2) | | Attention budget | The framing of context as a finite resource: a transformer needs every token to attend to every other, giving n² pairwise relationships, so capacity to model them is "stretched thin" as context grows. Hence: seek the smallest set of high-signal tokens. | R1 (Anthropic, T2) | | Lost in the middle | The U-shaped position effect: models use information best at the start or end of a context and significantly worse in the middle. Reproduced across six model families. | R1 (arXiv 2307.03172, TACL, T1) | | Event sourcing | Persisting state as an append-only sequence of events and reconstructing it by replaying them ("rehydration"), rather than storing current values. Named by Fowler in 2005 - and the pattern the 12-factor thread/state design rediscovers. | R1 (Azure Arch Center, T1) |

| Delegated authorization | Granting a third party a subset of your permissions on a fourth party's system, without sharing your credentials. The four-party shape is what makes it hard enough to need a protocol - and it is the shape of an agent calling a tool on your behalf. | S3 (&t=539s) | | Resource owner | OAuth's term for you - the human who owns the data and can click Yes. Most of OAuth's difficulty is vocabulary: the seven core terms are renames of ordinary things. | S3 (&t=990s) | | Front channel / back channel | Network-security terms, not OAuth ones. Front channel = the browser: usable to interact with a human, but observable (URL bar, extensions, shoulders). Back channel = server to server over TLS: unobservable. The whole flow shape follows from trusting the browser with the human and never with a secret. | S3 (&t=1634s) | | Scope | A named permission (contacts.read) the client requests up front, the user sees in plain language on the consent screen, and the issued token is bound to. Turns "access my account" into "read my contacts". | S3 (&t=1377s) | | Authorization code | A deliberately useless token: it crosses the browser in the open because redeeming it requires a client_secret that only exists on the back channel. The design assumes the channel is compromised and arranges for that not to matter. | S3 (&t=1937s) | | Access token vs ID token | An access token is for a machine - presented to an API, which decides what it permits; the client is not meant to read it. An ID token is for the app - it says who signed in and is never sent to an API. Confusing the two is the root of most OAuth/OIDC mix-ups. | S3 (&t=3126s) | | JWT ("jot") | JSON Web Token: a signed, base64url-encoded JSON envelope in three dot-separated parts (header, claims, signature). The signature lets a client verify authenticity locally, with no call back to the issuer. Signed, not encrypted - never put secrets in one. | S3 (&t=3234s) | | PKCE ("pixie") | Proof Key for Code Exchange: the fix for clients that cannot hold a client_secret. The client invents a per-request secret, sends only its hash up front, and reveals the original at exchange time - restoring "a stolen code is useless" without a back channel. | S3 (&t=3562s) |

| Harness | The orchestration around a model: how work is decomposed, what state passes between steps, who checks the output, when context is cleared. Not the model and not the prompt. Each component encodes an expiring assumption about what the model cannot do alone. | S4 (§1, §4c) | | Context anxiety | A model sensing it is near its context limit and prematurely wrapping up - declaring done, summarising, cutting scope - before the window is actually exhausted. Behavioural, not capacity-driven, and distinct from context rot. | S4 (§2) | | Context reset | Clearing the context window and restarting from a structured handoff artifact, as opposed to compaction (summarising in place). Only the reset removes context anxiety; the handoff artifact becomes the load-bearing part. | S4 (§2) | | Self-evaluation bias | The tendency of an agent asked to judge its own output to confidently praise it, even when a human would call the quality obviously mediocre. The reason a separate evaluator beats a self-critical generator. | S4 (§1, §2) | | Capability boundary | The frontier of what a model does reliably. Scaffolding is worth keeping only for tasks at or beyond it - so a component's value is boundary-relative, and a new model can turn essential scaffolding into pure overhead. | S4 (§4c) |

| Progressive disclosure (skills) | The three-layer loading contract of a skill: frontmatter (name + description) in context on every turn, SKILL.md body on trigger, references and scripts on demand. Each layer has a different price, which is the whole design constraint. | S5 (&t=159s) | | Capability skill vs preference skill | Capability: teaches what the model cannot do consistently yet - temporary, retire as models improve. Preference: encodes team workflow and convention - durable, must track the team. Opposite lifespans, so opposite eval purposes. | S5 (&t=194s) | | Trigger hijacking | A skill description broad enough that it fires on unrelated work ("use for any web development task" firing on Angular when it is a React skill), stealing context from tasks it cannot help. The fix is declaring negative cases. | S5 (&t=611s) | | No-op (skill instruction) | An instruction that does not alter the agent's behaviour - "write clear, high-quality code", "make the implementation easy to read". Common in AI-authored skills; burns reasoning tokens and obscures the real instructions. Credited to Matt Pocock. | S5 (&t=680s) | | Ablation (eval) | Running the same eval suite with and without a component loaded, and reading the delta rather than the absolute score. 94% vs 32% means the component is load-bearing; 96% vs 95% means the base model absorbed it and it is now pure context cost. The retirement test for any expiring scaffold. | S5 (&t=713s) | | Skill lift | The performance delta a skill produces in an ablation. SkillsBench 1.1: curated skills +16.6 pts (33.9% -> 50.5%); self-generated skills negative (-8.1 to -11.5). Also the merge criterion at Google DeepMind - no skill PR lands without proof of positive lift. | S5 (&t=266s,&t=1002s) |

| Dreaming | Memory maintenance as a background process on its own clock: it reads across many past sessions and rewrites the system's memory state between them, rather than appending during one. Named for sleep-time memory consolidation - the analogy is framing, not evidence, since no source here cites that literature. | S6 (§How memory has evolved) | | Saved memories | The write-once predecessor to dreaming: a flat, append-only list of atomic assertions about the user, written during a conversation on an explicit cue and never revisited. The shape that makes staleness structural. | S6 (§How memory has evolved) | | Memory staleness | The failure where a stored fact was true when written and is false now. Sharply distinct from irrelevance: a missing fact degrades an answer, a stale fact poisons it, because the system acts on it with full confidence. | S6 (§How memory has evolved) | | Implicit preference | Context that governs what is relevant to a user but is never uttered as an instruction ("I live near San Francisco"). The category explicit-cue memory capture structurally misses - as opposed to response instructions and stated constraints, which are easy to catch. | S6 (§Following preferences) | | Memory summary | The synthesized narrative rendering of what a system believes about a user, and the surface on which the user is offered correction in place of the underlying records. The design consequence: a correction may be an input to the next synthesis pass rather than a durable override. | S6 (§How memory has evolved) |

| Out-of-band (processing) | Work done outside the request path it affects - here, memory curation running between sessions rather than during them. Buys three things: cross-session vantage, no objective conflict with the task, and no latency cost. The general form: any loop asked to optimise two things trades them off untunably. | S7 (&t=764s) | | Optimistic concurrency control | Allowing concurrent writes without locking: each write carries a precondition (in S7, a content_sha256 of the content the writer believed it was editing) and fails rather than clobbering if the underlying state moved on. What lets many agents share one memory store safely. | S7 (&t=498s, frame_1030) | | Memory scope | The access level a memory store is attached at, and the unit of multi-agent memory design. Read-only org-wide stores hold slow-changing conventions readable by all agents; read-write task stores hold what one team's agents are currently learning. Multiple stores attach per session at different levels. | S7 (&t=466s) | | Procedural memory | Memory of how to do things rather than of facts. S7's memory ladder names skills as exactly this rung, which puts skills and memory in one family: a skill is procedural memory, a memory/ tree is the declarative kind. | S7 (&t=338s) | | Organizational memory | The end state S7 argues toward: memory grown from per-task notes into an org-wide store that functions as the model's understanding of how a whole company works, written by many agents and organised by a curation pass. | S7 (&t=873s) | | LLM Wiki | A persistent, interlinked markdown knowledge base an LLM writes and maintains between you and your raw sources - compiled once at ingest and kept current, rather than retrieved and re-synthesized per query. | S8 (gist @ac46de1, §The core idea) | | Query-time synthesis | Relating documents to each other when the question arrives. Cheap to build because nothing must be maintained, paid for on every question while the user waits, and discarded afterwards. The thing an LLM Wiki trades away. | S8 (gist @ac46de1, §The core idea) | | Lint (knowledge base) | A periodic, separately invoked health check over the whole store, hunting contradictions, superseded claims, orphans, missing pages and missing cross-references. Not a form checker - every item on the list is a judgement, which is why this kit calls its version dream instead (ADR-0010). | S8 (gist @ac46de1, §Operations) | | Memex | Vannevar Bush's 1945 proposal for a personal, curated document store where the trails between documents matter as much as the documents. Blocked for eighty years on maintenance labour rather than on storage or linking - which reframes the LLM's contribution as economic, not intellectual. | S8 (gist @ac46de1, §Why this works) | | Agent loop | The repeated cycle where an agent takes input, reasons over context, decides an action, optionally calls tools, observes the result, and continues until done. Six lines of pseudocode; the difficulty is the surrounding management of messages, tool schemas, errors, streaming, permissions and state. Whether you or your framework should own it is an open conflict - see claim 12 vs claim 75. | S9 (article, §Agent loops) | | Harness (as an inventory) | The runtime layer around an agent - tools, context, memory, planning, middleware, permissions. S9's contribution is enumerating it in four named columns rather than describing it in prose; S4's is the discipline for pruning it (claim 31). Read the two together. | S9 (article, fig_AgentHarness) | | Agent provider | A pluggable implementation that is the agent, rather than a model the agent calls - it brings its own loop, tools and context strategy. In S9's figure, whole third-party products (Claude Code, GitHub Copilot CLI) occupy this slot beside a wire protocol (A2A). | S9 (fig_AgentLoop, single-leg) | | Magentic orchestration | A vendor's name for the supervisor pattern: a coordinating agent plans and supervises work across subagents and tools rather than performing it. Same shape as S1's diagnoser meta-agent and S4's planner. | S9 (article, §Workflows) | | Author/Critic workflow | A workflow where one agent produces output and a separate one reviews or improves it, drawn as worker and reviewer in a cycle. The generator/evaluator split (claims 34, 59) as a named, reusable SDK primitive. | S9 (fig_Workflows) | | Tool selection (as middleware) | Choosing which subset of the available tools reaches the model on a given call, treated as a cross-cutting policy rather than per-call authoring. An instance of claim 20 - the tool list is a context-window decision like any other. Figure-only in S9; built and measured in S10 (claim 85). | S9 (fig_AgentHarness), S10 | | Tool search | Replacing the full tools/list manifest with two meta-tools - a search over an index of the catalog, and a registered dispatcher to call what it returns - so tool definitions enter context on demand instead of up front. | S10 (article, §Two tools instead of a hundred) | | Tool manifest | Every tool definition a client hands the model up front via tools/list: names, descriptions, JSON schemas, argument definitions. Resident in context on every turn, so its size tracks what is connected rather than what the task needs. | S10 (article, §intro) | | Aggregating MCP server | An MCP server whose tools come from other servers rather than from local implementations. Because the client sees only the aggregator's tools/list, it can index, hide, rename or add capability without any client or downstream server changing. | S10 (fig_image-6, single-leg) | | Prompt caching | Reusing an unchanged prompt prefix so the provider charges a fraction of the input-token price for it (~90% less on Azure OpenAI). Buys money and latency, never attention - cached tokens still compete for it. | S10 (article, §The default agent tax) | | Recall@k | The share of queries where the correct item appears anywhere in the top k results. Says nothing about its rank within those k, and nothing about the queries it missed. | S10 (article, §Retrieval quality was the real test) | | Cross-encoder reranker | A model that scores a query and a candidate together rather than comparing precomputed vectors. More accurate and far more expensive, because nothing can be indexed ahead of time: every candidate needs a forward pass at query time. | S10 (article, §Retrieval quality was the real test) | | Index-only field | Metadata indexed for retrieval but never shown to the consumer (additional_search_text), so search vocabulary and consumer-facing schema can be tuned independently - and a third-party corpus can be tuned without forking it. Also an invisible steering surface. | S10 (article, §Tuning the search space) | | Pinning (tools) | Keeping chosen tools permanently in the manifest instead of subjecting them to retrieval - the head of the Pareto distribution, plus whatever the agent must never have to rediscover. Also what keeps the prompt prefix stable enough to cache. | S10 (article, §Search is for the long tail) | | Semantic layer | A declarative definition of metrics and entity relationships (ARR, pipeline, active usage) sitting above the physical tables, so "revenue" resolves to one agreed calculation instead of being re-derived per query. Long-standing BI infrastructure (LookML, 2012) repurposed as agent context. | S11 (article, §The semantic model defines metrics and relationships) | | ELT | Extract, load, transform - land raw data in the warehouse first, then transform in place with SQL (typically dbt), as opposed to older ETL which transformed before loading. The default shape of a modern data stack. | S11 (visuals/fig2) | | Endorsement (data asset) | A flag marking an asset as trusted, so an agent or a human prefers it among several that touch the same concept. Only informative while scarce, so it needs a writer restriction; Power BI ships two tiers (open Promotion, restricted Certification). | S11 (article, §Endorsements) + Microsoft Learn (T1) | | Knowledge acquisition bottleneck | The limiting factor in a knowledge-based system is the human labour of extracting expert knowledge and encoding it usably, not the system's reasoning power. Identified by Feigenbaum in 1977 and never solved, only made cheaper - LLMs collapse the encoding half and leave elicitation untouched. | R2 F5 (Feigenbaum 1982, Stanford archive, T1) | | Execution accuracy (EX) | The standard text-to-SQL metric: the fraction of generated queries whose result set matches the gold query's, rather than whose SQL text matches. Measures the answer, not the phrasing. | R2 F1 (BIRD / Spider 2.0) |

| Hub-and-spoke (multi-tenant) | A central shared environment (the hub) connected to multiple isolated environments (the spokes), where spokes never connect to each other. In S12: shared routing and governance hubs, one cloud project per business unit. | S12 (§Architecture) | | Principal Access Boundary (PAB) Policy | A policy attached to a set of principals capping which resources they may reach at all, whatever IAM otherwise grants them. IAM is additive and distributed; a principal boundary is subtractive and central, and it wins. The mechanism S12 points at a compromised agent identity. | S12 (§Architecture, n4) | | VPC Service Controls perimeter | An organisation-scope boundary around cloud services that blocks data crossing it - an exfiltration control, distinct from an access control. | S12 (§Architecture) | | Identity-Aware Proxy (IAP) | A reverse proxy that authenticates the caller and evaluates access policy before the request reaches the application, so the application never sees an unauthenticated request and implements no login of its own. | S12 (§Architecture, n5) | | Prompt injection | Text arriving through data - a message, a document, a tool result - that the model treats as instructions. The defining property: the attacker needs no access to your systems, they write English and the agent, which does have access, carries it out. | S12 (§Agentic flow, n5) - the brain's first source to place a filter for it | | Identity propagation | Carrying the original caller's identity across a service hop so the far end authorizes as that user rather than as the calling service. Without it the calling service is a confused deputy: broad access, acting on requests it cannot fully vet. Required, and unspecified, for S12's shared MCP server. | S12 (§Design alternatives, MCP servers, n11) | | Noisy neighbour | One tenant degrading another's service by exhausting a shared finite resource - in S12, a shared model endpoint's quota pool. A multi-tenancy failure with nothing to do with security, removed for free by a per-tenant boundary bought for security reasons. | S12 (§Reliability + §Cost, n13) | | Structural vs enforced isolation | Whether an isolation guarantee is a property of where a component sits (holds even if the component is carelessly written) or of code someone wrote (holds only if identity is attached, propagated unforgeably and authorized correctly on every call). Sharing a component converts the first into the second. | S12 - this brain's framing of n10/n11, not a term the source uses (claim 106) |

S1 = sources/260725_closed-loop-evals-multimodal-agent/ (Uber, AI Engineer World's Fair 2026). S2 = sources/260725_12-factor-agents/ (Dex Horthy / HumanLayer, AI Engineer World's Fair 2025). S3 = sources/260725_oauth2-oidc-plain-english/ (Nate Barbettini / Okta, 2018). S4 = sources/260725_harness-design-long-running-apps/ (Prithvi Rajasekaran, Anthropic Labs, 2026). S5 = sources/260726_dont-ship-skills-without-evals/ (Philipp Schmid, Google DeepMind, AI Engineer WF 2026). S6 = sources/260731_chatgpt-memory-dreaming/ (OpenAI, 2026-06-04). S7 = sources/260731_claude-memory-dreaming/ (Anthropic, "Code w/ Claude", 2026-05-21). S8 = sources/260731_llm-wiki/ (Andrej Karpathy, gist ac46de1, 2026-04-04). S9 = sources/260801_agent-framework-layered-sdk/ (Shawn Henry, 2026-05-28). S10 = sources/260801_tool-search-toolboxes/ (Lisa Brown Jaloza, Microsoft, 2026-07-29). S11 = sources/260802_agent-data-stack/ (Emily Hawkins, LangChain, 2026-07-27). | Episodic vs semantic memory | Episodic memory is bound to a time and place ("on 2026-07-10 the migration failed"); semantic memory is decontextualised fact ("this project prefers TypeScript"). Endel Tulving's 1972 distinction, imported wholesale into agent design. Episodic is the raw material; semantic is what learning produces. | F (memory-taxonomy-and-lifecycle.md) | | Procedural memory | Knowing how, as against knowing that (semantic) or knowing when (episodic). The third member of the cognitive-science memory family, and the category an agent skill occupies. | F (memory-taxonomy-and-lifecycle.md) | | Reflection (memory) | Distillation applied to its own output: when accumulated importance crosses a threshold, the agent synthesises abstract insights from recent memories and stores them as new higher-importance ones. The threshold is the design decision - it makes synthesis periodic and out of band. | F (memory-taxonomy-and-lifecycle.md) | | Godel machine | Schmidhuber's theoretical self-improving program, which rewrites itself only on a proof the rewrite helps. Safe by construction, and impossible in practice - which is why it sat unbuilt for two decades. | S22 (n1) | | Darwin Godel Machine | The same loop with empirical benchmark evidence substituted for the proof, plus a Darwinian archive of every agent produced. The substitution is what makes it buildable and what makes it able to be wrong. | S22 (n1, n3) | | Archive (vs lineage) | Keeping every agent a self-improving search has produced and selecting parents from all of them, rather than always modifying the current best. Ablation-confirmed necessary: hill-climbing plateaus lowest, because one bad self-modification damages the only agent you have. | S22 (n8) | | Viability gate | Admitting only agents that compile and retain the ability to edit a codebase. Deliberately not a quality bar - a liveness invariant kept separate from the performance metric, so a self-modification cannot end the run by breaking the tool it needs to modify itself. | S22 (n5) | | Frozen meta-level | Putting the search procedure itself - archive maintenance, parent selection - outside what a self-improving system may modify. The thing that decides what counts as improvement must not be inside what improves. | S22 (n6) | | Amplification of the unmeasured | A self-improving loop optimises what it can measure and compounds what it cannot. Observed in S13 (a banked random seed), predicted adversarially in S19 (V-S5), and stated by S22's builders of their own system. Claim 124 is the frame: the verifier sets the rate of improvement and of silent degradation. | S22 (n12); S19 (n4); S13 (claim 114) | | Out-of-band defence | The field's term for the structural class: enforce security outside the model with a deterministic policy mediating the agent's actions, rather than training the model to refuse. Used as standard vocabulary in two 2026 preprints - S21's telecom analogy adopted by the literature (R3). | | Over-defence | A defence that blocks legitimate work in order to block attacks, measured as utility loss rather than attack success. The failure mode a single security score hides, and the one AgentDyn finds in almost every deployed defence - including CaMeL at 0.00% utility on open-ended tasks (R3). | | Planning-dependent defence | A defence that fixes the agent's permitted actions from an initial plan - tool filters, CaMeL, DRIFT. Strong where the plan can be written before the work starts, and severely over-defensive where it cannot (R3). | | Spotlighting | A family of input transformations that make untrusted text's provenance continuously perceptible, paired with a system prompt describing the transformation. Three variants: delimiting, datamarking, encoding. | S21 (n2) | | Datamarking | Interleaving a marker token throughout the body of untrusted text (In^this^manner^Cosette), rather than only at its edges. ~50% to 3.1% attack success at no measurable task cost - and it resists forging, because provenance becomes a property of every token. | S21 (n5, n6) | | In-band / out-of-band signalling | Whether control information shares a channel with data or travels on a separate one. From telephony, where in-band multi-frequency stopped accidental interference and was defeated intentionally by phone phreaking. Spotlighting is in-band; its authors name out-of-band as the real answer and call it infeasible in current model architectures - a requirement S18 met one level up, in a program. | S21 (n12) | | Dynamic marking token | Randomising a datamarking marker and its positions per invocation, so a leaked system prompt is stale on leak and an adversary is reduced to a 1/N^k guess. The general move: depend on a value that changes faster than it can be learned, not on a secret. | S21 (n9) | | Benign utility / utility under attack / targeted ASR | AgentDojo's three metrics. What the agent solves with no attacker; what it still solves while attacked; and how often the attacker's goal is met. The second's complement is untargeted attack success, which is denial of service. | S20 (n4, n5, n7) | | Inverse scaling (security) | The measured finding that more capable models are easier to attack, because a weak model fails at executing the attacker's multi-step goal for the same reason it fails at the user's. The safety of a weak agent is incompetence, not robustness. | S20 (n6); qualitatively S17 (n10) | | Tool filter | An isolation defence: have the model choose the tools its task needs before it observes untrusted data, then restrict it to those. The Pareto winner at 7.5% attack success - and it fails on the 17% of cases where the task's own tools also suffice for the attack. | S20 (n12, n13) | | Adaptive attack evaluation | Testing a defence against attacks designed for that defence, rather than against a fixed set. The reason AgentDojo is an extensible framework rather than a static benchmark - a static attack set invites defences tuned to it. | S20 (n17) | | Memory write channel | A path by which content reaches an agent's long-term memory. Four exist: explicit command (C1), system-prompt retention policy (C2), compaction (C3), experience-to-procedure (C4). Only C1 is a command - the other three are decided by the model's own judgement, which is why command-detection misses most of the surface. | S19 (n2) | | Strong-signal / weak-signal attack | Whether a payload carries linguistic markers a classifier can recover from raw input. Weak-signal payloads read as ordinary domain content and are stored for satisfying a retention policy, not for issuing a command - which is why detection collapses on them by up to 42 points. | S19 (n5, n12) | | ASR / RSR (memory poisoning) | Attack success rate (did the adversarial content get written?) against retrieval success rate (did it influence behaviour in a later session?). RSR is the one that measures persistence. | S19 (n7, n8) | | Self-improvement as amplification (V-S5) | In an agent that refines its own skills, a poisoned step that runs without error is treated as validated, so the loop optimises the adversarial procedure over time. Stated to have no equivalent in static memory systems. Claim 114 with an adversary choosing the noise. | S19 (n4) | | Write-path provenance tracking | Recording where each memory entry originated so retrieval policies can demote or quarantine untrusted sources. S19's central architectural proposal, and S18's mechanism aimed at a surface S18 does not cover - neither carries provenance across a session boundary. | S19 (n14); cf. S18 (n5) | | Dual LLM pattern | Splitting an agent so a privileged model plans and holds tools while a quarantined model is the only one that touches untrusted content and has no tool access. Protects the plan; does not protect the arguments. | S18 (n2) | | Capability (security) | Metadata attached to a value recording its provenance and who may read it, so authority travels with the data rather than being looked up per-caller. Checked when a tool is called, not when data is read. Prior art: libcap, Capsicum, CHERI. | S18 (n5) | | Information Flow Control | Tracking where each value came from and where it may go, so a secret cannot reach a public sink even if some component is willing to send it. The classical discipline CaMeL ports to agents. | S18 (n1, n5) | | Control Flow Integrity | Constraining execution to the edges a program's structure allows. The model for CaMeL - and a cautionary one, since CFI was bypassed by return-oriented programming, chaining individually-valid fragments, which the authors expect to have an analogue here. | S18 (n16) | | Privileged / Quarantined LLM | CaMeL's two roles. The P-LLM sees only the trusted user query and writes code, never seeing tool output. The Q-LLM parses untrusted data, holds no tools, and may return only schema-conforming output plus one boolean - a free-text reply would be a re-injection channel. | S18 (n3, n4) | | De-classification | Deciding when restricted data may leave its restriction. Where a capability system meets a human, and where fatigue and rubber-stamping begin. | S18 (n17) | | Indirect prompt injection | The hostile instruction is planted in data the agent will read - a page, a row, an email, a tool result - rather than typed at it. The attacker never contacts your system. Every retrieval surface is therefore an injection surface. | F (agent-threat-model.md) | | Memory poisoning | Corrupting a persistent store so it contaminates every future context that retrieves from it. Two mechanisms: a stored instruction that fires on retrieval, and retrieval manipulation, where attacker content simply ranks above legitimate context and nothing needs to fire. S16 is the measured instance of the second mechanism and shows it needs one record. | F (agent-threat-model.md); measured in S16 (n1, n5) | | Indirect prompt injection | The attacker places text in a source the target's agent will retrieve, and never touches the target's system - no account, no session, no request to block, because the fetch was issued by the victim's own application to a source it trusts. Distinct from the direct kind, where the attacker is the user typing into the interface. | S17 (n2) | | Data-instruction blur | The property that makes all of it possible: retrieval places untrusted content and system instructions in one flat token sequence with no type distinction, so processing retrieved data is analogous to executing arbitrary code. There is no parameterised prompt, because instruction-following is a learned disposition rather than a parser with a grammar. | S17 (n1) | | Prompts as worms | An injection that instructs its host agent to propagate it - reading the user's address book and forwarding itself, for instance - so it spreads with no further attacker action. | S17 (n5) | | Agent persistence | Compromise surviving a session reset, achieved by getting the injection into the agent's own long-term memory so a fresh session re-poisons itself on read. The point where S16 and S17 independently meet (claim 145). | S17 (n6); S16 (n1, n5) | | Multi-stage injection | A tiny first payload on a public page whose only job is to make the model fetch a much larger second one from attacker infrastructure, so the text that must survive review is a single sentence. | S17 (n9) | | The filtering dilemma | Why input filtering resists a clean fix: a filter capable enough to decode obfuscated or encoded injections is itself instruction-following and therefore injectable, while one too weak to be injected is too weak to decode them. | S17 (n14) | | Backdoor (agent) | A dormant behaviour planted in a system that fires only on a secret trigger, leaving normal operation intact. Distinct from a jailbreak, which is loud, and from an availability attack, which degrades everything. Benign behaviour is a design objective, which is what makes it hard to notice from monitoring alone. | S16 (n12) | | Trigger (backdoor) | The short token sequence that, when present anywhere in a query, causes the poisoned records to be retrieved. Optimised rather than chosen, constrained to read as fluent language, and demonstrably effective at one token. | S16 (n5, n8) | | Poisoning ratio | The fraction of a retrieval store that is attacker-written. The number worth knowing is how low it can go: S16 operates below 0.1% and demonstrably at a single record, which is what removes the volume signal anomaly detection depends on. | S16 (n4, n5) | | Uniqueness / compactness (adversarial retrieval) | The two objectives that make retrieval poisoning cheap. Uniqueness pushes triggered-query embeddings away from where benign queries fall; compactness pulls them together, so a handful of poisoned records covers all of them. Together they let the attacker stop competing for similarity and simply occupy an empty region. | S16 (n3) | | Perplexity filter | A defence that rejects input whose text is statistically surprising under a language model, on the reasoning that gradient-optimised strings are weird in a way human text is not. Works against GCG. Defeated by construction once the attacker's objective includes a fluency term. | S16 (n7) | | Isolate-then-aggregate | A RAG defence that runs the model separately against each retrieved record and aggregates the answers, assuming poison is a minority of the retrieved set. S16 targets that assumption by poisoning all k neighbours - argued, never measured. | S16 (n10) | | Transferability (adversarial) | An attack optimised against one model working against another it never saw. For retrieval triggers this reaches black-box commercial embedders at ~0.68-0.78 success, on the argument that the attack targets a semantically empty region rather than an artifact of particular weights. | S16 (n6) | | Operator / user / environment | The three-tier trust hierarchy for where an instruction came from: operator (system prompt) is highest, user (the human turn) is bounded by it, and environment (tool results, retrieved documents, memory) has no authority at all - it is data. Every injection attack is tier three being treated as tier one. | F (agent-threat-model.md) | | Bi-encoder vs cross-encoder | A bi-encoder embeds query and document separately, so similarity compares two summaries that never met - cheap, indexable, approximate. A cross-encoder reads the pair together and scores the relation - accurate, and far too slow to run over a corpus. This asymmetry is the entire reason retrieval has a separate rerank stage. | F (grounding-and-retrieval.md) | | Hybrid search | Running sparse (term-matching, e.g. BM25) and dense (embedding) retrieval together and fusing the rankings. Justified because their failure modes are near-complementary: sparse misses paraphrase, dense misses rare identifiers, codes, names and negation. | F (grounding-and-retrieval.md) | | Chunking | Splitting documents before embedding. Too small loses the context that made a passage meaningful; too large dilutes one embedding across several topics so it matches everything weakly. A retrieval-quality parameter, not a preprocessing detail. | F (grounding-and-retrieval.md) | | N x M problem | Without a protocol, N agents times M tools means N x M bespoke integrations. A protocol collapses it to N + M: each tool publishes one server, each agent connects as one client. The argument for MCP in one line. | F (tool-use-and-mcp.md) | | Agent-computer interface (ACI) | The discipline of designing tools to be usable by models, named by explicit analogy to HCI. A model's ability to use a tool correctly is bounded by how well the interface communicates its semantics - so the description is not documentation about the interface, it is the interface. | F (tool-use-and-mcp.md) | | Sampling (MCP) | The primitive that runs the other way: the server asks the host's model for a completion. It is what lets a server stay model-agnostic rather than shipping its own inference. | F (tool-use-and-mcp.md) |

| Bits per byte (BPB) | A language-model score that divides total prediction surprise by the number of bytes of text rather than tokens, so models built on different tokenizers are comparable. Lower is better. The point generalises: pick a denominator the thing being optimised cannot redefine. | S13 (prepare.py:343-365 @ 228791f) | | Wall-clock budget | Holding elapsed time constant across experiments rather than steps or tokens, so every change - architecture, model size, kernel efficiency - competes on how well it spends a fixed slice of time. Makes efficiency part of the objective without putting it in the metric. | S13 (n3) | | Noise floor | How much a metric moves between identical runs, for reasons unrelated to any change made. Any accepted improvement smaller than it is unresolved. Measured almost for free by re-running one configuration with a different random seed. The first thing to measure in an automated accept/reject loop and the last thing anyone thinks to. | S13 (n12) | | Greedy hill climbing / coordinate descent | A search that accepts any single change improving the current best and continues from there, one variable at a time. Needs no gradient and is trivial to implement; cannot reach an optimum that requires two changes at once, because each alone makes things worse. The default behaviour of any keep-if-better loop. | S13 (n13) | | Rollback-safe ledger | The rule that in a loop whose discard operation is a rollback, the audit trail must live outside the rolled-back state - otherwise the record of a failed attempt is destroyed along with the attempt. In S13: the code is committed, the results file is deliberately untracked. (Name is this brain's; the source states only the instruction.) | S13 (n7) | | Goodhart's law (mechanical form) | When a measure becomes a target it stops being a good measure. The version that matters for agent loops is not about incentives but about plumbing: any degree of freedom that changes the metric's units improves the number without improving the thing, and an optimizer will find it with no intent to cheat. | S13 (n4, and this brain's framing) |

| Generation-verification gap | The distance between what a model can produce somewhere in its sample set and what any available selector can actually extract from it. Generation is cheap and scales with compute; verification does not, so the gap widens with problem difficulty - ~0.87 against 1.0 on GSM8K, ~0.40 against ~0.95 on MATH. The binding constraint on every sampling-based method. | S15 (n10, n11) | | Mechanical verifier | A correctness check whose result does not depend on a model's judgement - a proof assistant, a test suite, a compiler, a simulator. The distinction that matters is not automated against manual, but grounded outside the model against produced by another model. Its availability, not model capability, decides where repeated sampling pays. | S15 (n8) | | Exponentiated power law (inference scaling) | c = exp(a·k^b), relating coverage c to sample count k. Its exponent is a property of the benchmark's difficulty distribution as much as of the model, because the power law exists only where a long tail of very hard problems drags out the per-problem exponentials. | S15 (n3, n5) | | Parallel sampling vs sequential revision | The two axes of test-time compute. Parallel draws k independent attempts and explores, producing both the diversity that gives coverage its power and the disagreement that makes selection hard. Sequential conditions each attempt on the previous ones and exploits, inheriting earlier correctness and earlier mistakes alike. | S15 (n14) | | Outcome vs process reward model (ORM / PRM) | An ORM scores a finished answer; a PRM scores each intermediate step, where a step is a semantically meaningful chunk and explicitly not a token. Step-level scores are what turn repeated sampling into beam search over reasoning steps, since you no longer have to wait for a complete answer to abandon a bad line. | S15 (n16, n17) | | Fusion (inference-time operation) | Handing a model all k candidates and asking it to synthesize one answer, rather than selecting among them. Reported to beat oracle selection, which is impossible under the selection frame and is the evidence that the frame was wrong - a synthesis can combine a correct approach from one candidate with a correct calculation from another. (S15 needs-check: authors' own result, one unnamed benchmark.) | S15 (n25) |

⚠️ pass@k collides across sources, and the collision is already recorded. S1 means sequential retries with QA feedback between them; S14 and S15 mean k independent samples with no feedback. S15 adds the sharper distinction to carry: coverage (pass@k) is an existence claim about a candidate set, pass@1 is a delivered result, and conflating them is claim 132.

S12 = sources/260802_gcp-multi-tenant-agentic-ai/ (Google Cloud Architecture Center, reviewed 2026-06-18). S13 = sources/260803_autoresearch/ (Andrej Karpathy, karpathy/autoresearch, code snapshot 228791f, 2026-03-26). S14 = sources/260804_cs329a-self-improving-agents/ (Stanford CS329A lecture 1, 6YnLB0XbTnI, 2026-08-03). S15 = sources/260804_cs329a-test-time-compute/ (Stanford CS329A lecture 2, -Ggc37xLj_Y, 2026-08-03). Not independent of S14. S16 = sources/260804_agentpoison/ (AgentPoison, arXiv 2407.12784, 2024-07-17). T3 preprint, no vendor. S17 = sources/260804_indirect-prompt-injection/ (Greshake et al., arXiv 2302.12173, 2023-02-23). T3 preprint, no vendor. S18 = sources/260804_camel-prompt-injection-defense/ (CaMeL, arXiv 2503.18813, 2025-03-24). T3 preprint; efficacy measured on the authors' own benchmark. S19 = sources/260805_memory-poisoning-systematic/ (Dash et al., arXiv 2606.04329, 2026-06-03, AIWILD@ICML). T3, workshop-reviewed. S20 = sources/260805_agentdojo/ (AgentDojo, arXiv 2406.13352, NeurIPS 2024 D&B Track). Peer-reviewed; shares two authors with S18. S21 = sources/260805_spotlighting/ (Spotlighting, arXiv 2403.14720, Microsoft, 2024-03-20). T2/T3 vendor preprint; no venue, no code. S22 = sources/260805_darwin-godel-machine/ (Darwin Godel Machine, arXiv 2505.22954, ICLR 2026). Peer-reviewed main track, open code, real ablations. | Stateless protocol | One where every request carries everything needed to serve it, so no request depends on an earlier one and any server instance can handle any call. A claim about a layer, never about a system - the state is relocated, not eliminated (claim 180). | S23 (n3, n10) | | Session pinning / sticky affinity | Load balancer configuration keeping one client bound to one backend, required when the backend holds conversation state in memory. Costs even distribution and autoscaling efficiency, and does not survive a restart. | S23 (n1, n2) | | _meta (MCP) | The field on every MCP request carrying what the initialize handshake used to negotiate once - protocol version, client capabilities and client info - under io.modelcontextprotocol/ namespaced keys. | S23 (n3) | | MRTR (Multi Round-Trip Request) | MCP SEP-2322. Turns a server-to-client question into two independent requests: the server returns an InputRequiredResult with a requestState the client echoes back, so any instance can resume. | S23 (n7) | | Client-held server state | State a server serializes, hands to a client, and accepts back rather than storing. Standard and good, with one non-negotiable requirement - it must be integrity protected, because the client can otherwise rewrite it. Signed cookies and JWT signatures exist for this; base64 is transport encoding and protects nothing. | S23 (n8, claim 181) | | requestState | The MRTR blob carrying serialized server execution context through the client between the two halves of an elicitation. Unsigned plaintext in S23's own example, beside a file-deletion confirmation. | S23 (n7, n8) | | Tasks extension (MCP) | MCP SEP-2663. A long-running tool returns a taskId immediately and executes in the background; the client polls tasks/get or subscribes to tasks/update. The protocol-level form of the serialise-and-resume pattern claim 15 reached from agent design. | S23 (n9) | | ttlMs / cacheScope | MCP SEP-2549 cache hints modelled on HTTP Cache-Control, telling a client how long a result stays fresh and whether it may be cached across users. The second is a multi-tenancy control described in half a sentence. | S23 (n6) | | Confused deputy | A component with broad privileges acting on instructions it cannot fully vet, so the caller borrows its authority. A token minted for server A and presented to server B is the canonical MCP instance; RFC 8707 resource indicators are the standard fix, adopted by MCP 2026-07-28. | S23 (n11, claim 182) | | Resource indicator (RFC 8707) | An explicit statement by the client of which server a token is intended for, so the token cannot be replayed against a different one. Audience restriction - the mechanism mcp.md and agent-security.md both asked for and neither earlier source could name. | S23 (n11) | | Deep packet inspection (protocol routing) | A gateway parsing request bodies to route or police them. MCP's promotion of Mcp-Method and Mcp-Name into HTTP headers removes the need for it, letting ordinary infrastructure govern MCP traffic without understanding MCP. | S23 (n4, n5) | | Session key | A deterministic routing identity composed from source fields (profile, platform, chat, thread, sometimes participant) that chooses which conversation lane an inbound event lands in. Distinct from the session ID, which names the conversation itself. Which fields are in it is the isolation policy (claim 185). | S24 (n1, n2) | | Session ID | The identity of one durable conversation incarnation - the stored transcript and metadata to load. A reset changes it while the session key does not move. Conflating the two is claim 184's category error. | S24 (n1) | | Active-run guard | The in-memory guarantee that one session key has at most one turn running in one process. Because it is memory-only it is process-local: it dies with the process and does not hold across two gateway processes (claim 191). | S24 (n8) | | Delivery obligation | A durable record that a response exists and owes a delivery, written around a platform send and moving through pending, attempting, delivered, failed, abandoned. Buys at-least-once recovery, never exactly-once - an ambiguous crash mid-send is resolved by warning a human. | S24 (n19) | | Provider tuple | The resolved set of provider, model, endpoint, client and API mode that actually served a call. Fallback can replace the whole tuple mid-run, which is why telemetry must record what served the call rather than what was selected (claim 193). | S24 (n15) | | Entry surface | A door into an agent system - a CLI, a messaging adapter, an editor protocol - owning ingress and egress for its channel and no part of the run. Two surfaces can share every piece of runtime machinery and still own two conversations (claim 184). | S24 (n4, n23) | | Capture the flag (CTF) | An exercise in which a secret string is hidden inside deliberately vulnerable software, retrievable only by finding and exploiting a flaw - so holding the flag proves the exploit worked. This is why it is a usable eval: the grader needs no judgement. | S25 (n1) | | Zero-day / one-day | A zero-day vulnerability is one nobody has disclosed or patched. A one-day has been disclosed and patched, and the attacker's work is reverse-engineering the public fix to reach systems whose operators have not deployed it yet. In an eval these are not difficulty tiers, they are named real-world scenarios selected by how much the agent is told (claim 197). | S25 (n4) | | CVE / CVSS | A Common Vulnerabilities and Exposures identifier is the public catalogue entry for a disclosed flaw. Its CVSS score runs 0-10, and "critical" means 9.0 or above, implying remote exploitability with full compromise. | S25 (n5) | | Proof of concept (PoC) | An input that makes a bug fire, demonstrating the flaw is real. It is not an exploit, and the distance between the two is exactly the rung where measured capability stops (claim 200). | S25 (n3, n11) | | Sanitizer | Instrumentation compiled into a binary that checks every memory access and deliberately crashes on a violation, converting a silent memory-safety bug into a loud detectable event. Built by the security field for fuzzing, decades before anyone benchmarked a model - and the reason exploitation evals can be deterministic when most domains cannot (claim 124 seen from its good end). | S25 (n11) | | ASLR / KASLR | Address Space Layout Randomization shuffles where code and data sit in memory on every run, so an attacker cannot rely on hardcoded addresses. KASLR is the same defence for the kernel. One of the ordinary mitigations holding the cliff in claim 200. | S25 (n14) | | First Solve Time (FST) | The wall-clock time the first human team took to solve a challenge in its original competition, used as a difficulty unit denominated in human effort rather than in a synthetic score. | S25 (n6) | | Best-of-N / Best@N | A score computed by running N independent attempts and keeping the best. It is an existence claim about a candidate set, not a delivered success rate - claim 132's subject, and undisclosed in all three benchmarks that used it in S25. | S25 (n8, n22) | | Agent-as-a-judge | Using a model to assess another agent's transcript or output. Contested in adversarial settings by claim 164, because judge and subject can share a vulnerability, and used by two of S25's benchmarks anyway (d7). Note that inter-auditor agreement measures agreement, not correctness. | S25 (n13) | | Idempotence stamp | A marker written into an item recording that an operation has completed on it, checked before the operation runs so repeated invocations skip finished work. What turns a maintenance pass from O(store) into O(new), and therefore what makes it safe to schedule (claim 206). | S26 (n5) | | Long-context retrieval (in-context retrieval) | Placing an entire corpus in the model's context and letting attention do the retrieving, with no index, embeddings or retriever. Matches RAG pipelines at 128k tokens and degrades at 1M - so it is a real alternative with a measured ceiling, not a replacement (claim 213). | R4 / LOFT (T3) | | Positional degradation | Accuracy falling as the answer-bearing document moves toward the end of a long context. The mechanism behind claim 213's ceiling, and the reason it is a ceiling rather than a hard limit: the model is not refusing the volume, it is failing to attend across it. | R4 / LOFT (T3) | | Agentic search | Retrieval by an agent using ordinary file tools - glob, grep, read - iteratively, instead of an embedding index. Never stale and nothing to keep in sync, since it reads live files; the trade is latency, and it degrades on cost before it degrades on quality (claim 213). | R4 | | Curation labour ceiling | The point where a curated catalog stops scaling because summarising and filing outruns editor capacity - what killed the Yahoo Directory. The one of a catalog's two ceilings that an LLM removes (claim 214). | R4 | | Controlled vocabulary | A curated list of terms that annotations must be drawn from, extended only deliberately and never silently. The library-science answer to everybody inventing a different label for the same thing; here a registry file the agent must read before tagging (claim 207). | S26 (n6) | | Faceting | Splitting annotation into independent axes so orthogonal properties do not compete for one slot - "what this is about" kept apart from "what kind of thing it was". The cheapest defence against a vocabulary where a medium and a topic contend for the same tag. | S26 (n6) | | Entity page | A derived page about a person, organisation or concept, assembled from every source that mentions it rather than summarising any one of them. The unit in which accumulation becomes visible: the page existed in none of its inputs. | S26 (n9) | | Per-claim citation | Sourcing at the granularity of the individual assertion rather than the document, so a wrong claim is traced by following one link instead of re-reading the whole provenance list. What makes a generated page debuggable (claim 210). | S26 (n9) | | Instantiability | That a described pattern can be built and run by someone other than its author. A real and separate fact from efficacy, and the only thing a faithful re-implementation establishes about its source (claim 212). | S26 (n1) |

F = a foundations/ file - supplied background, uncited by construction. A term attributed to F was not learned from a gated source; it is vocabulary this brain supplies so the rest reads. Treat it as a definition, never as a finding. R1 = deep-research pass on S2, sources/260725_12-factor-agents/context/01_context-limits-and-decomposition.md. R3 = deep-research pass on S18, sources/260804_camel-prompt-injection-defense/context/01_independent-evaluation-and-the-2026-defence-landscape.md. AgentDyn, independent of S18. R2 = deep-research pass on S11, sources/260802_agent-data-stack/context/01_data-agent-accuracy-and-prior-art.md. R4 = deep-research pass on S8's n10, sources/260731_llm-wiki/context/01_where-the-index-file-ceiling-actually-sits.md. LOFT (T3, Google DeepMind) and a LlamaIndex benchmark (T2), independent of S8 and of each other.