Glossary — the LLM-wiki
16 terms the rest of this curriculum leans on, plain language first. These entries define;
they deliberately make no volatile product claims — those live in the modules, with chips.
Glossary entries carry no chips of their own — that is the point of the page. The legend below
is here so a reader who arrives at a definition from a module link can decode the chips they
came from without navigating away.
How to read the chips
- ✓Confirmed checked against Anthropic’s own page on the date shown, and the receipt kept.
- ▪Documented carried from the working group’s document (context as of July 2026), not re-checked since.
- ⚠︎Stale risk known-volatile, or the check found a discrepancy — treat as a question, not a fact.
- ⚑compliance a claim a patient-data decision could hang on — always confirm with your Anthropic contact first.
- ✎our practice the group’s recommended practice, not an Anthropic product fact.
Terms
"In the weights"
"In the weights" describes knowledge a model learned during training and can recall on its own — as opposed to information you supply it in the moment, which it only "knows" because you put it in front of it.
Full entry
Detail
A model’s weights are the parameters set during training; whatever the model can produce correctly without being handed source material in the conversation is, informally, “in the weights.” The alternative is grounding: giving the model the specific facts, documents, or context it needs at the time of the question, rather than relying on what it may have absorbed during training. This distinction matters enormously for rare-disease work, because rare conditions are, by definition, thinly represented in almost any general training data, so a model’s unprompted, in-the-weights knowledge about a specific rare disease can be shallow, outdated, or simply wrong even when it sounds confident. The trap: assuming fluent, confident-sounding answers mean the disease is well represented in the weights. The only way to know is to regularly test the model against real patient- and clinician-facing questions and supply current, vetted information in context rather than trusting recall alone.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
aDNA (context graph)
`aDNA` is the naming convention for the context graph behind this site — a versioned folder of fact files, one claim per file, each carrying its source, its retrieval date, and an honest confidence rating. The footer's `RareAnthropic.aDNA` names that folder.
Full entry
Detail
The term matters here for one reason: it is the answer, demonstrated, to the working group’s own question “how can we control what sources Claude pulls from?” An assistant instructed to answer from a curated graph — instead of from its general memory — is constrained by whatever the graph contains, and every page of this site is rendered from exactly that graph. Control the graph and you control the sources; the graph’s provenance chips are what make the control auditable.
Source & currency
- Source: definitional term (teaching aid) — this is the project’s own infrastructure vocabulary, not an Anthropic product term.
Artifact
An artifact is the standalone piece of work Claude produces beside the chat — a document, a web page, a diagram — designed to be kept, reused, or shared on its own.
Full entry
Detail
Artifacts earn a glossary entry because of the secrets rule that names them: an artifact is made to travel — it can be shared, published, or copied out of the conversation that produced it — so anything pasted into one should be assumed to outlive, and escape, the chat. That is why “not in an artifact” is the third clause of the never-paste rule, alongside the chat itself and any folder Claude can read.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
BAA — Business Associate Agreement
A BAA is a signed contract that lets a vendor legally handle protected health information on a covered entity's behalf — without one, sharing patient health data with that vendor is not permitted under HIPAA.
Full entry
Detail
A Business Associate Agreement is the contract HIPAA requires between a covered entity (or another business associate) and any vendor that creates, receives, maintains, or transmits protected health information for it. The agreement obligates the vendor to specific safeguards and breach-notification duties, and it is what makes handling PHI with that vendor lawful in the first place. For an AI product, a BAA typically applies only to specific, named configurations — not to the vendor’s product line as a whole, and not automatically the moment a contract is signed. The trap: assuming a general enterprise or business contract with a vendor is the same thing as a BAA, or assuming that because one product tier is covered, a sibling tier or feature is covered too. Always confirm which exact configuration is under a signed BAA before any PHI touches it.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
Connector
A connector is a permission you grant Claude to reach a specific outside service — a shared drive, a messaging tool, a registry platform — so it can read (and sometimes act on) real data there instead of you copy-pasting it in.
Full entry
Detail
A connector links Claude to an external application or data source so it can retrieve information, and in some cases take action, without a person manually exporting and pasting content into the conversation. Under the hood this is typically built on a protocol like MCP, but the everyday reality for a working group is simpler: turning on a connector is a scope decision, not a convenience toggle. Whatever the connector is authorized to reach is what Claude can see for as long as that authorization stands — including files or channels well beyond the one task that prompted the connection. For advocacy organizations juggling several nonprofits’ data, this is exactly where cross-org exposure risk lives. The trap: granting a connector broad, standing access “to save time later” instead of scoping it to what one task actually needs, then forgetting it is still connected once the task is done.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
Covered Model
"Covered Model" is Anthropic's designation for certain models whose prompts and outputs carry a *mandatory* retention requirement — they must be kept for a fixed window, even in setups built to retain nothing.
Full entry
Detail
The designation matters because it cuts against the intuition that retention is always something you can turn down: for a Covered Model, a retention window is a condition of using the model at all, which is also why such models are unavailable under Zero Data Retention arrangements. Which models are designated, and how long the window is, are product facts that move — they live in the modules, with chips, not here.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For which models are currently designated and the current window, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
Cowork
Cowork is the Claude surface where Claude *works alongside you on files* — you grant it folders, and it reads, edits, and produces documents in a working session, rather than only answering in a chat.
Full entry
Detail
The word appears throughout this curriculum because Cowork sits at the center of two different questions that must not be blurred: a security question (its sessions are isolated — but the isolation protects your machine from the code Claude runs, not you from what Claude reads through the access you granted) and a coverage question (whether the surface is inside your organization’s BAA at all). Cowork’s session mechanics, and its compliance status — which is exactly the kind of fact that moves — live in the modules, with chips.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For what Cowork’s isolation does and does not protect, and its current BAA status, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
De-identification
De-identification means stripping out enough identifying detail from health information that it can no longer reasonably be traced back to a specific person — HIPAA recognizes two accepted ways to do this.
Full entry
Detail
HIPAA recognizes two accepted paths to de-identification. Safe Harbor removes a specific list of 18 identifier types — names, dates, locations, contact details, and other direct identifiers — leaving no reasonable way to link the data back to a person through those fields. Expert Determination instead has a qualified statistical expert assess and certify that the risk of re-identifying someone from the remaining data is very small, which can allow more detail to be kept than Safe Harbor’s fixed checklist would. For a rare-disease organization, this distinction matters because rare conditions are themselves quasi-identifying — a small enough patient population, combined with even a few remaining details, can point back to one person even after the obvious identifiers are gone. The trap: treating de-identification as “remove the name and birthdate” and stopping there, instead of checking whether the disease’s rarity, combined with whatever details remain, still narrows things down to an identifiable individual.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
Guardrail
A guardrail is any constraint put around a model to steer its behavior — instructions, policies, filtering, or structured context — meant to make its answers safer and more consistent, not to make them perfect.
Full entry
Detail
A guardrail is a deliberate constraint placed around how a model behaves: a system prompt that sets rules for a conversation, an organizational policy about what may be typed in, output filtering that catches certain kinds of content, or structured context — like this graph — that shapes what a model draws on before it answers. Guardrails can be layered — a well-run advocacy workflow typically has several working together, from what staff are trained not to paste in, to what the tool itself restricts. The trap: treating guardrails as a guarantee rather than a reduction. A guardrail lowers the rate and severity of errors; it does not eliminate them, and an output that passed through several guardrails still deserves the same human judgment as one that did not.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
MCP — Model Context Protocol
MCP is an open standard that lets an AI assistant connect to outside tools and data sources — like a universal adapter, rather than a one-off custom integration for every service.
Full entry
Detail
The Model Context Protocol is an open specification for how an AI assistant talks to external tools, applications, and data sources in a consistent way, so a connection built once can work across compatible assistants rather than needing bespoke code per service. It is the plumbing underneath many “connector” features — when Claude connects to a drive, a messaging tool, or a registry platform, MCP (or something built on the same idea) is often how that connection is described and governed. For advocacy work, the practical point is one of scope — and it is not that a connection is confined to what you granted it. A local MCP server is a program running on your computer, with your permissions. Anthropic’s own safety guidance says so directly: “Local MCP servers bundled with plugins and desktop extensions run on your computer with the same permissions as any other program you run.” The same page warns that plugins “bundle together skills, connectors, and sub-agents into a single package, which means installing one can significantly expand Claude’s scope of action,” and — worth reading twice — that “Network egress permissions don’t apply to the web fetch or web search tools or MCPs.”
Whether a remote, hosted connection behaves differently is a reasonable expectation and not something the cited page says either way — it draws no local/remote distinction at all, and its egress warning is unqualified as to hosting model. Treat that as an open question rather than a reassurance. The trap is treating “we connected it” as a small, contained decision: installing a local MCP server or plugin is closer to installing software than to ticking a permission box. Anthropic’s guidance is to “stick to verified extensions from the Claude Desktop directory, and carefully evaluate the permissions any extension or plugin requests before installing.”
Source & currency
- Source: definitional term (teaching aid) for the protocol itself · Use Claude Cowork safely — Claude Help Center for the local-server permission model (receipt R30).
- Corrected 2026-07-27 (CG4). This entry previously told readers that an MCP connection “only exposes what it has been granted access to, nothing more and nothing less.” An enumerated search of Anthropic’s safety page (§4.4) found no such statement and found two that run the other way — local MCP servers run with the user’s full permissions, and network-egress permissions do not apply to MCPs at all. This was a security claim, stated confidently, in a glossary whose stated policy is to carry no volatile product claims — the worst place on the site for it, because a glossary is what a reader trusts without checking. The corrected text is sourced to Anthropic’s safety page (receipt R30). Note for the reader: glossary entries deliberately render no provenance chip — the chip taxonomy is for claim cards — so the citation lives in this line rather than in a badge. That is also part of why a volatile security claim should never have been here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
PHI — Protected Health Information
PHI is health information tied to an identifiable person — a name, a diagnosis, a date of birth, a rare-disease case description — that HIPAA protects once it's held or shared by a covered entity or its business associates.
Full entry
Detail
Protected Health Information is individually identifiable health information — anything about a person’s condition, care, or payment for care that could reasonably identify them, held or transmitted by a covered entity or a business associate. It doesn’t take a name to make something PHI: a rare enough diagnosis, a specific age plus location plus condition, or a distinctive combination of details can identify someone even with obvious identifiers stripped out. This matters constantly in advocacy work, where case counts, patient stories, and registry entries are exactly the kind of small, distinctive datasets where “anonymous” can quietly become “identifiable” again once details are combined. The trap: treating de-identification as a one-time redaction instead of checking the combination of remaining details for whether they still point to one person.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
Primary Owner
The Primary Owner is the one account role that "owns" an organization's Claude workspace — the person able to accept organization-level agreements on its behalf. If you are not sure whether you are your org's Primary Owner, you almost certainly aren't — find out who is before planning any step that needs one.
Full entry
Detail
Several org-level actions in Claude are reserved to this single role rather than to admins generally — accepting a Business Associate Agreement is the example this curriculum cares about. For a small nonprofit the practical consequence is scheduling, not technology: the enablement step can only be done by one named person, so identify them early. Which actions are Primary-Owner-only on which plan is a product fact that moves — it lives in the modules, with chips.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For what the Primary Owner must do on each BAA path, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
Prompt injection
A prompt injection is an instruction hidden inside content Claude *reads* — an email, a web page, a shared document — aimed at Claude rather than at you. Claude may follow it. This is the central safety idea behind every access decision on this site.
Full entry
Detail
The attack needs two things to do damage: something malicious for Claude to read, and something consequential for Claude to be allowed to do. Every folder grant, connector, and app permission is a decision about one of those two conditions, which is why narrowing either one is the actual defense. This entry only defines the term — the full, sourced treatment (Anthropic’s own definition, the two-condition analysis, and what it means for connectors and folder access) is an established node: Prompt injection: instructions hidden in content Claude reads.
Source & currency
- Source: definitional term (teaching aid) — the sourced claim lives on the linked ESTABLISHED node.
Retention (data)
Retention is simply how long your conversations, files, and their contents are kept after you've used them — and whether that stored content can also be used to train future models.
Full entry
Detail
Retention describes what happens to a prompt, a file, or a conversation after the immediate task is done: whether it is deleted quickly, kept for a defined window, or kept indefinitely until a person deletes it, and, separately, whether it is eligible to be used for training future models. These are different questions, and they are answered differently across plan types and even across features within the same plan, which is why “what is our retention” rarely has one single answer for an organization. For advocacy work, retention is the practical lens on a simple question: if something sensitive were typed in by mistake, how long does that exposure window stay open, and could it resurface later? The trap: assuming one setting governs everything — how long content is kept, whether it can train future models, and whether a given feature follows the same rules as ordinary chat are each their own check, not one you can infer from the others.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
Skill (Claude)
A Skill is a reusable, packaged set of instructions — like a house-style guide or a template Claude reads before doing a specific kind of task — that loads automatically when it's relevant, instead of being retyped every time.
Full entry
Detail
A Skill is built around a single instructions file — optionally paired with scripts or reference material — that teaches Claude how to handle one specific, recurring task: an abstract-review rubric, a funder-report format, a registry-intake template. Unlike custom instructions, which apply to every conversation all the time, a Skill loads only when it is relevant to the task at hand, which keeps general conversations uncluttered while still giving specialized, repeatable work a consistent, checkable format. For a small advocacy team, a good Skill is documentation and automation in one place — it captures how the group has agreed to do a task, so the next person does not start from scratch or drift into their own version. The trap: building a Skill only one person understands or maintains, so it quietly goes stale, or letting several people build near-duplicate Skills for the same task instead of sharing one — the opposite of the consistency a Skill is supposed to deliver.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.
ZDR — Zero Data Retention
Zero Data Retention is a contractual arrangement where your prompts and the model's outputs aren't stored once they've been processed — they pass through and are gone, rather than sitting in logs.
Full entry
Detail
Zero Data Retention is an arrangement, typically negotiated on top of a standard API or platform agreement, under which prompts and outputs are used only for the real-time processing needed to generate a response and are not kept afterward — no logs sitting around for days or weeks. It matters for advocacy organizations because it shrinks the window in which sensitive text could ever be exposed through a storage breach, even though it does not by itself make a product HIPAA-eligible or PHI-safe. The trap: assuming ZDR is a single, uniform switch that covers a whole product. In practice, individual features can be excluded from ZDR coverage even when the surrounding product has it enabled, so “is ZDR on” is a question to ask feature-by-feature, not once for the whole account.
Source & currency
- Source: definitional term (teaching aid) — no volatile product claim is made here.
- For current product specifics, see the linked ESTABLISHED nodes — and confirm compliance-critical specifics with your Anthropic contact.