Data Access Service

one_liner: Catalog a live, queryable endpoint as a first-class typed object — distinct from a static download — so discovery can tell 'query the current state' from 'pull a snapshot' and read the access terms off the record.

core_idea:
A data access service is a named, addressable endpoint cataloged as a continuing interface through which clients can query, filter, or retrieve data from one or more datasets on demand — as distinct from a static downloadable artifact that represents the dataset's content at a point in time.

The W3C Data Catalog Vocabulary defines `dcat:DataService` as the inverse complement of `dcat:Distribution`: where a Distribution is a concrete snapshot you can download (a CSV file, a Parquet dump, a Zip archive), a DataService is a live endpoint you can query repeatedly (a SPARQL interface, a REST API, an OGC Web Map Service, an FTP host with refreshing content). Both are catalog-side descriptions of how a dataset is accessed; the DataService description captures the continuing, interactive case.

The structural commitment has four constitutive components. The *catalog entry* is a typed record that names the service as a service, not a static form — this typing is what lets a discovery query distinguish "can I query this interactively?" from "can I download this?" The *endpoint URL* is the dereferenceable address clients use to issue requests. The *served-dataset relation* binds the service to the one or more datasets it exposes, so a consumer who finds a dataset in the catalog can navigate from the dataset to all services that expose it. The *conformance declaration* names the protocols, query languages, authentication schemes, and rate policies the client must honor — the contract that makes the service reachable on known terms rather than by trial and error.

The practical effect is that a data catalog can represent *continuing live access* as a first-class object alongside static distributions, enabling discovery to answer both "where can I download a snapshot?" and "where can I run a query against the current state?" A researcher looking for a biodiversity registry finds the bulk CSV distribution for offline analysis and the SPARQL endpoint for interactive queries; both appear under the same dataset identifier in the catalog, each with its own conformance declaration. The same shape appears in any API marketplace listing (endpoint plus auth scheme plus capability), in a corporate data catalog binding an analytics schema to a JDBC service, and in NASA's catalog binding a geospatial layer to an OGC WMS endpoint. In each case what the catalog is capturing is not merely "here is where data lives" but "here is how this data is reachable, on what terms, and under what protocol."

scope_of_application:
The data access service lives within data-cataloging and access-infrastructure description — the subfields where a catalog must type a *continuing, queryable* interface as a first-class object distinct from a static distribution; its reach is within that descriptive-infrastructure substrate (the reception-desk/switchboard/consular-window analogues are co-instances of the parent primes — interface, access_control, service — not of this catalog-typing apparatus).

- **Government open-data portals** — the reference setting: data.gov and EU portals expose the same dataset via `dcat:DataService` (SPARQL, REST) and `dcat:Distribution` (bulk download), and the typing lets discovery answer "queryable now?" separately from "downloadable?"
- **Commercial API marketplaces and directories** — each listing pairs an endpoint URL with supported operations and an auth scheme, the conformance declaration that settles "reachable by me, on what terms?" before a request.
- **Enterprise data catalogs** — Collibra, Alation, and OpenMetadata bind an analytics schema to a JDBC or query service alongside its datasets, so analysts discover not just what data exists but how to query it.
- **Scientific and geospatial data infrastructure** — ESA, NASA, and NOAA publish via OGC services, OPeNDAP, and custom REST endpoints, each cataloged as a typed service with its protocol and conformance named.
- **Linked-data and semantic-web catalogs** — SPARQL query services described as `dcat:DataService` with a named protocol conformance and a served-dataset relation navigable from dataset to interface.

structural_signature:
**Sig role-phrases:**

- **the typed catalog entry** — a record that names the service *as a service* (`dcat:DataService`), the inverse complement of a static distribution
- **the endpoint URL** — the dereferenceable address clients use to issue requests against the live interface
- **the served-dataset relation** — the link binding the service to the one or more datasets it exposes, navigable from dataset to interface
- **the conformance declaration** — the named protocols, query languages, authentication schemes, and rate policies a client must honor
- **the live-versus-snapshot guarantee** — the type flag answers "query current state repeatedly" versus "pull a point-in-time form" categorically, without inspecting the endpoint
- **the reachable-on-terms guarantee** — the conformance declaration settles "usable by me, within what limits?" before any request is issued
- **the dataset-identity-invariance** — the service is bound to but distinct from its datasets, so access surfaces are enumerated without fusing into the dataset's identity
- **the catalog-typing limitation** — the discovery value lives in the catalog-side typing apparatus, which has bite only where datasets carry both snapshot and queryable forms

what_it_is_not:
- **Not a static downloadable form.** A data access service is the live, continuing interface — a SPARQL endpoint, a REST API, an OGC service — that lets a client query the *current state* repeatedly; it is the inverse complement of a `dcat:Distribution`, which is a point-in-time snapshot pulled once. The same dataset legitimately carries both, so the question is never "service or distribution?" but "which access mode does the workflow need?"; treating a refreshing endpoint as a snapshot (or a download as a query interface) mismatches the access mode.
- **Not the dataset it serves.** The service is bound to one or more datasets by the served-dataset relation but is held distinct from them. The dataset's identity is invariant while its access surfaces come and go, so adding or retiring a service extends or trims the dataset's reachable-on-terms footprint without touching what the dataset *is*. The endpoint is a route to the data, not the data.
- **Not a guarantee the data is reachable by you.** That a service is cataloged establishes that it exists and on what terms — not that your tooling and credentials can use it. The conformance declaration names the protocols, query languages, authentication, and rate policies a client must honor; "the data exists" and "the data is reachable by me, within these limits" are separate facts, and a failure to honor a declared term is a client-side contract violation, not a service outage.
- **Not the running endpoint itself.** A data access service in this sense is the *catalog-side typed record* describing the endpoint — its discovery value lives in the typing (a record typed `dcat:DataService` that a discovery query can find and filter), not in the bytes the live server returns. The server can be up while no catalog entry exists, and an entry can describe an endpoint that is temporarily down; the concept is the description that makes the interface discoverable, not the infrastructure that answers requests.

clarity:
Typing a service as a service is what makes the catalog answer a question it otherwise cannot: not "where does this data live?" but "how is it reachable, and on what terms?" Before the DataService/Distribution split, a catalog that listed only downloadable forms forced two genuinely different access modes — pull a snapshot once, or query the current state repeatedly — into one undifferentiated "here is the data," so a discovery query could not tell a CSV dump from a live SPARQL interface. Naming the data access service makes that distinction first-class: a consumer can now ask "can I run a query against the present state?" separately from "can I download a point-in-time artifact?", and the catalog can return both under one dataset identifier, each correctly typed.

The concept also lifts the access contract out of trial-and-error and into the catalog record. The conformance declaration — protocols, query languages, authentication, rate policies — names the terms on which the endpoint is reachable, so the difference between "the data exists" and "the data is reachable by me, on these terms" becomes legible before a single request is issued. This sharpens what the catalog is for: discovery now ranges over reachability and protocol, not just existence and location. And by binding a service to the datasets it serves, the concept lets a consumer who has found a dataset navigate outward to every interface that exposes it — keeping the dataset's identity stable while its access surfaces (a bulk download, an API, a map service) are enumerated as distinct, separately-contracted routes rather than collapsed into the dataset itself.

manages_complexity: A dataset can be reachable in a sprawling number of ways — a CSV dump, a Parquet archive, a SPARQL interface, a REST API, an OGC map service, a refreshing FTP feed — each with its own protocol, query language, authentication, and rate policy, and each either a one-time snapshot or a live query against current state. A consumer browsing a catalog otherwise has to read all of that off prose, documentation, or trial-and-error against each access surface. The data access service compresses that variety into a single typed catalog object carrying four slots — typed entry, endpoint URL, served-dataset relation, conformance declaration — so discovery reasons over a uniform record rather than over the open-ended particulars of every interface. The type flag alone collapses the most consequential branch: it answers "snapshot or live query?" categorically, without inspecting the endpoint, and the conformance declaration settles "reachable by me, on what terms?" before any request is issued. Because the service is bound to its served datasets while remaining distinct from them, the dataset's identity stays fixed while its access surfaces are enumerated as a small, separately-typed set rather than fused into the dataset description. The move is from each consumer independently working out how every route behaves to scanning a handful of standardized fields per route, and reading the access mode and contract straight off the catalog.

abstract_reasoning:
The four typed slots — typed entry, endpoint URL, served-dataset relation, conformance declaration — let a catalog consumer draw discovery inferences from the record alone, before issuing a request.

*Diagnostic / classification (read the access mode off the type flag).* The single most consequential inference is categorical and requires no inspection of the endpoint: a record typed `dcat:DataService` means *the current state can be queried repeatedly and interactively*; a record typed `dcat:Distribution` means *a point-in-time snapshot can be pulled once*. From the type alone the consumer infers which of two genuinely different access modes is on offer — live query against present state versus download of a frozen artifact — and therefore which analytical workflows are even possible (a filtered slice of current data demands the service; an offline reproducible cut demands the distribution). The reasoning move is to *condition the whole access plan on the type flag* rather than discovering the mode by trying the endpoint and seeing what happens.

*Diagnostic (read reachability-on-terms off the conformance declaration).* The conformance declaration lets the consumer infer, in advance, whether the resource is reachable *by them*: the named protocol, query language, authentication scheme, and rate policy together answer "can I, with my tooling and credentials, actually use this, and within what limits?" The inference separates "the data exists" from "the data is reachable by me on these terms" — a consumer can predict an authentication wall, an unsupported query language, or a rate ceiling from the record, and rule a service in or out *before* a single request is issued. Failure to honor a declared term is thereby diagnosable as a client-side contract violation rather than a service outage, because the terms were stated up front.

*Interventionist (the access plan follows from the typed record).* The combination of type flag and conformance declaration dictates the consumer's next action and predicts its outcome. If the need is a repeated filtered query and the catalog exposes a DataService whose conformance names a query language the consumer speaks, the predicted-effective action is to *issue queries against the endpoint*; if the need is an offline snapshot, the predicted-effective action is to *pull the bound Distribution instead*. Choosing the wrong route is predicted to fail in a mode-specific way — querying a static distribution gives stale or no interactivity; downloading from a live service to get a reproducible artifact gives a moving target. The catalog record is thus an instruction for *which* access to attempt, not merely a pointer to where data lives.

*Boundary-drawing (service-versus-distribution, and service-versus-dataset).* Two boundaries fall out. The first decides which catalog object a given access surface *is*: a continuing, interactive, current-state endpoint is a DataService; a concrete, downloadable, point-in-time form is a Distribution — and the same dataset legitimately carries both, so the question is never "which one is it?" but "which surface do I need?" The second boundary holds the *service distinct from the dataset it serves*: the served-dataset relation binds them without fusing them, so the inference is that the dataset's identity is invariant while its access surfaces (a bulk download, an API, a map service) are enumerable as a small set of separately-contracted routes. A consumer who has found a dataset can therefore navigate outward to *every* interface that exposes it, and reason about each interface's terms independently, without those terms reflecting back onto the dataset's identity.

*Predictive (discovery ranges over reachability and protocol, not just existence).* Because access mode and contract are first-class typed fields, the concept licenses discovery queries that an existence-and-location catalog cannot answer: "which datasets are *queryable* under SPARQL?", "which expose a REST service I can authenticate to?", "which offer only static dumps?" The prediction is that adding a new access surface to a dataset changes what discovery returns for that dataset along the reachability axis while leaving its identity and other surfaces untouched — so a publisher reasons about exposing a service as *extending the dataset's reachable-on-terms footprint*, a move evaluated separately from the dataset's content and from its other routes.

knowledge_transfer:
Within data-cataloging and access-infrastructure description the concept transfers *as mechanism*, with its full diagnostic apparatus intact. A practitioner who understands `dcat:DataService` carries the same four-slot template — typed entry, endpoint URL, served-dataset relation, conformance declaration — across every catalog substrate in the family: government open-data portals (data.gov, EU portals exposing SPARQL + REST + bulk download), commercial API marketplaces (endpoint + supported operations + auth scheme), enterprise data catalogs (Collibra, Alation, OpenMetadata binding an analytics schema to a JDBC service), and scientific data infrastructure (ESA, NASA, NOAA publishing via OGC, OPeNDAP, custom REST). In each, the service-versus-distribution type flag means the same thing (live query against current state versus one-time snapshot), the conformance declaration answers the same "reachable by me, on what terms?" question before any request, and the served-dataset relation supports the same dataset-to-interfaces navigation. These are co-instances of one cataloging discipline, not analogies — the operational knowledge (catalog services as a distinct type, declare conformance and endpoint, link to served datasets) moves to a new portal design without translation.

Beyond the data-catalog substrate the honest reading is case (B): the concept does not travel as a unit because, stripped of its DCAT framing, it *decomposes* into more-general primes that travel separately. The load-bearing reasoning machinery — a named, addressable endpoint that mediates access (the parent prime `interface`), governed by terms of use (`access_control`), routed to a backing capability (`service`) — recurs across genuinely distinct domains as co-instances of *those* primes: a building's reception desk mediating access to its occupants, a switchboard, an embassy's consular window, a librarian's reference desk are all interface-plus-access-control-plus-service in the same abstract sense, none of them "like" a DCAT DataService by resemblance. What does *not* travel out is the home-bound cargo: the catalog-side *typing* discipline itself (a record typed `dcat:DataService` as the inverse complement of `dcat:Distribution`), the served-dataset relation as a navigable catalog link, the conformance declaration as a machine-readable field, and the "live query versus static download" distinction that only has bite where datasets have both snapshot and queryable forms. That apparatus is descriptive-infrastructure machinery specific to data catalogs; it is the *cataloging implementation* of the underlying primes, not a structural move that recurs elsewhere. So when the lesson is needed in a non-data-infrastructure setting, the thing to carry is the parent — an addressable, contract-bearing interface that mediates access to a resource — and not "data access service," whose DCAT typing and served-dataset machinery is a domain instance that does not survive extraction. Calling a reception desk a "data access service" renames the slots and borrows the shape while dropping the catalog typing that gives the original its discovery value; that is analogy, and should be marked so (see *Structural Core vs. Domain Accent*).


Data Card

one_liner: Attach a fixed-schema documentation artifact to a dataset at its publication boundary — recording motivation, composition, recommended and out-of-scope uses, consent, and known limitations — so a consumer meets the dataset's boundary conditions at the same moment as the data.

status: draft

core_idea:
A data card is a structured, portable documentation artifact that travels with a dataset and records the conditions of its creation — motivation, composition, collection methods, preprocessing decisions, recommended uses, out-of-scope uses, ethical considerations, and known limitations — so that any downstream consumer encounters the dataset's boundary conditions at the same moment they encounter the data itself.

The structural commitment is that metadata about the dataset is codified in a standardized schema, attached at the publication boundary, and written to be read before reuse rather than discovered after the fact. The schema is the critical discipline: it enumerates the dimensions along which any dataset must be characterized, forcing the documentation author to confront and record what was done, what was excluded, who was included or overrepresented, what consent or rights govern downstream use, and what the known gaps and failure modes are. A downstream consumer of many datasets faces an otherwise combinatorial problem — each dataset may have different scope, coverage, collection period, label definitions, licensing terms, and ethical exposure. The card schematizes these dimensions to a common axis set, making datasets comparable and making reuse decisions auditable.

The pattern was articulated by Gebru et al. (2018) under the name "Datasheets for Datasets," drawing an explicit analogy to the technical datasheets that travel with electronic components and specify operating conditions, tolerances, and failure modes — a convention that allows engineers to select and combine components without testing each individually against every possible operating condition. Applied to datasets, the analogy disciplines: a dataset reused without a card is like a component used without a datasheet, where the consumer does not know the rated conditions and cannot know when they are operating outside them. The parallel "Model Card" formulation by Mitchell et al. (2019) extends the idea from datasets to trained models, and Hugging Face has operationalized both as structured metadata fields on its hub, making card-style documentation a routine expectation for shared ML artifacts.

The card is positioned at the publication boundary, not the creation boundary — it travels with the dataset as it is shared, cited, and reused across contexts that the original creators did not anticipate. This boundary placement is what gives it force: a documentation artifact that stays internal to the creating team does not intercept reuse decisions; a card that is mechanically attached to any distribution of the dataset does. The practical exemplar: a medical-imaging dataset released with a card stating the collection hospitals (three urban academic centers), date range (2015–2019), demographic distribution, label definitions and inter-rater reliability, IRB terms and consent scope, and known confounds (camera-vendor variation, lighting differences by site) allows a downstream researcher to assess whether their intended application population matches the dataset's representational scope before training, rather than discovering the mismatch after deployment.

scope_of_application:
The data card lives in ML data governance as its home, extending to its in-family siblings and the adjacent data-publishing settings that co-adopt the same schema-plus-boundary-placement discipline; its reach is within that data-documentation domain. The broader cross-domain "card" form (nutrition labels, datasheets, package inserts) belongs to a candidate `schematized_boundary_disclosure` prime and to the general primes the card composes (metadata, interface documentation, `provenance`), not to "data card" as named, and stays out of this map.

- **ML dataset publication** — the home turf: the "Datasheets for Datasets" practice (Gebru et al.) attaching a fixed schema of motivation, composition, collection, recommended-and-out-of-scope uses, consent, and known confounds at the dataset's release boundary.
- **Model and system cards** — the near siblings (Mitchell et al.) extending the same move from datasets to trained models and deployed systems, with the schema enumerating the axes each artifact must be characterized on.
- **ML artifact hubs** — Hugging Face operationalises dataset and model cards as structured, required metadata fields, routinizing card-style documentation for shared ML artifacts.
- **Research data repositories** — ICPSR, Dryad, and similar deposit forms require schematized description and provenance at the publication boundary, co-adopting the discipline through their own required-fields schemas.
- **Government open-data portals** — attach standardized metadata describing scope, collection, and rights to published administrative datasets.
- **Medical-imaging registries** — document collection sites, date range, demographic distribution, label definitions, IRB and consent scope, and known confounds so downstream researchers can judge representational fit before training.
- **Corporate data catalogs** — enforce required-field schemas describing internal datasets' scope, lineage, and reuse terms at the point of sharing.

structural_signature:
**Sig role-phrases:**

- **the documented artifact** — the dataset (or, for siblings, the trained model or system) treated as a boundary-crossing object that will be shared, cited, and reused beyond its origin
- **the fixed schema** — the enumerated axes any dataset must be characterized on: motivation, composition, collection methods, recommended uses, out-of-scope uses, consent and rights, known confounds and limitations
- **the common axis set** — the standardization that makes otherwise idiosyncratic datasets describable in the same coordinates and therefore directly comparable
- **the producer's checklist function** — the schema doing double duty: converting "what should I disclose?" into a finite enumeration whose unfilled entries surface representational gaps
- **the publication-boundary placement** — the load-bearing position: the card is mechanically attached to every distribution, written to be read before reuse, so boundary conditions arrive at the same instant as the data
- **the portability** — the property that distinguishes a card from a methods section or internal README: it travels with the artifact and cannot be skipped on the path to reuse
- **the suitability-before-deployment guarantee** — the warranted payoff: a consumer reads representational scope against intended application and judges fit before training rather than discovering mismatch after deployment
- **the absence-is-the-warning corollary** — the characteristic diagnostic: a dataset reused without a card, or with an empty field, is operating outside known conditions by default; the missing disclosure is itself the risk signal

what_it_is_not:
- **Not a certificate of dataset quality.** A data card *discloses* the conditions of creation and reuse; it does not vouch that the dataset is good, unbiased, or fit. A complete, conscientious card can describe a narrow, skewed, confounded dataset — that is exactly its job. Reading the presence of a thorough card as a clean bill of health inverts its function: the card surfaces limitations so the consumer can judge them, it does not certify their absence.
- **Not a guarantee of fitness for a use.** The card states the dataset's *rated conditions* — populations, time range, label definitions, confounds — but the suitability judgment is the consumer's: match the representational scope against the intended application *before* training. The card does not approve uses or warrant that any given application is safe; a dataset within scope for one task is out of scope for another, and the card supplies the facts for that decision rather than making it.
- **Not "documentation that exists somewhere."** Placement is load-bearing: the same facts in a methods section, an internal README, or the creators' tacit knowledge do not intercept the reuse decision. What distinguishes a card is that it is mechanically attached to *every distribution* and written to be read before reuse, so it cannot be skipped on the path to the data. A buried datasheet is not a data card in the sense that matters; portability at the boundary is the point.
- **Not merely provenance.** The card *includes* origin-and-custody, but it extends past provenance to recommended and out-of-scope uses, consent and rights, ethical considerations, and known limitations. Treating a data card as a provenance record drops precisely the forward-looking, reuse-governing fields — what the data should and should not be used for — that distinguish it from a record of where the data came from.
- **Not version control or lifecycle tracking.** A card is a *snapshot at one boundary* — the dataset's publication point — keyed to a version but not itself implementing change-tracking or bidirectional lineage links across the artifact's life. It states the conditions of *this* release; it does not track how the dataset evolves or trace links across its lifecycle, which is the work of versioning and traceability, not the card.

clarity:
Naming the data card makes visible a failure mode that "we should document our datasets" leaves diffuse: the systematic asymmetry between when dataset knowledge is *available* (at creation, inside the producing team) and when it is *needed* (at reuse, by a consumer the producers never met). Without the concept, dataset documentation defaults to a README that stays with the project, a paper buried in a citation, or tacit knowledge in the creators' heads — none of which intercepts the moment a downstream practitioner decides to train on the data. The data card reframes the problem from "is the dataset documented?" to "does the boundary condition arrive at the same instant as the data?", which is a question about *placement and portability*, not merely about whether the information exists somewhere. That reframing is what distinguishes a card from a methods section: both may contain the same facts, but only the card is mechanically attached to every distribution, so it cannot be skipped on the path to reuse.

The schema is the card's second clarifying act. By enumerating the axes along which any dataset must be characterized — composition, collection, recommended and out-of-scope uses, consent and rights, known confounds — it converts the open-ended, easily-evaded question "what should I disclose?" into a fixed checklist that forces the author to confront representational gaps they might otherwise leave unstated. This makes two practitioner questions newly answerable. For the producer: which dimensions of my dataset's scope have I not yet pinned down, and which omissions would a reuser need to know about? For the consumer: does this dataset's representational scope — its populations, time range, label definitions, rights — match my intended application, *before* I train rather than after I deploy? The sharper diagnostic the concept supplies is that a dataset reused without a card is operating outside known conditions by default: the absence of the disclosure is itself the warning, locating the risk at the publication boundary rather than leaving it to surface as an unexplained downstream failure.

manages_complexity: A practitioner deciding whether to reuse one dataset among many confronts a combinatorial assessment: every dataset differs in scope, population coverage, collection period, label definitions, consent and licensing terms, and ethical exposure, and characterizing each on its own idiosyncratic terms means re-deriving the reuse decision from scratch for every candidate — an open-ended audit with no fixed shape. The data card's schema collapses that sprawl onto a common axis set. By fixing in advance the dimensions along which any dataset must be characterized — motivation, composition, collection, recommended and out-of-scope uses, rights, known confounds and limitations — it makes datasets describable in the same coordinates and therefore directly comparable, so a consumer reasons over a short list of standardized fields rather than over the unbounded particulars of each source. The schema does double duty as the producer's checklist, converting "what should I disclose?" into a finite enumeration that surfaces representational gaps the author would otherwise leave unstated. And because the card is fixed at the publication boundary and travels mechanically with every distribution, the boundary conditions arrive at the same instant as the data, so the consumer reads suitability — does this dataset's scope match my application? — off the card before training rather than reconstructing it after a downstream failure. The move is from a per-dataset, dimensionally-unbounded reuse assessment to a fixed-schema disclosure whose common axes make the whole comparable and whose absence is itself the warning that one is operating outside known conditions.

abstract_reasoning:
The data card licenses a set of reasoning moves that turn on its fixed schema and its placement at the publication boundary — each running from the card's standardized fields, or from their absence, to an inference about reuse fitness, ethical exposure, or what disclosure is still missing.

*Diagnostic — match representational scope to intended application.* The consumer's central inference reads the card's composition-and-collection fields against the planned use. Confronting a candidate dataset, the practitioner reasons from the recorded scope — collection sites, date range, demographic distribution, label definitions and inter-rater reliability, known confounds — to whether the dataset's representational population covers the intended application population. A medical-imaging dataset collected at three urban academic centers across 2015–2019, with a stated demographic distribution and camera-vendor and site-lighting confounds, supports the inference that an application targeting a rural or pediatric population, or a different imaging vendor, falls outside the dataset's rated scope. The move is to make a suitability judgment *before training* off the card's fields, rather than discovering the mismatch after deployment — the card is what lets the boundary condition arrive at the same instant as the data.

*Diagnostic — absence of the card is itself the warning.* Because the card is mechanically attached at the publication boundary and written to be read before reuse, the consumer reasons from its absence to a default verdict: a dataset reused without a card is operating outside known conditions, because the disclosure that would have stated the rated conditions never arrived. The inference runs from "no card, or a card with an empty field" to "the conditions of safe reuse are unknown here," locating the risk at the publication boundary rather than waiting for it to surface as an unexplained downstream failure. An empty out-of-scope-uses field or an unstated consent scope is read not as a clean bill of health but as an undischarged disclosure.

*Interventionist — close the gap the schema surfaces.* For the producer, the schema doubles as a checklist, so the author reasons from each enumerated axis to whether that dimension of the dataset's scope has been pinned down, and treats any axis left unstated as a representational gap to close. The move runs from "which schema fields are unfilled or vague?" to "these are the omissions a reuser would need, so fill or flag them" — converting the easily-evaded question "what should I disclose?" into a finite enumeration whose unfilled entries are the work. The predicted effect is that completing a previously-blank axis (recommended versus out-of-scope uses, rights and consent terms, known confounds) removes a specific downstream failure mode the omission would otherwise have caused.

*Boundary-drawing — what the card governs, and what placement makes it bite.* The card bounds two things. First, its scope of disclosure: it records the conditions of *creation and proper reuse* — motivation, composition, collection, recommended and out-of-scope uses, rights, limitations — and the analyst reasons that questions outside those axes are not what the card answers. Second, and decisively, the card's force depends on *placement*: the same facts in a methods section, an internal README, or the creators' tacit knowledge do not intercept the reuse decision, whereas a card attached to every distribution cannot be skipped on the path to reuse. The move is to distinguish a card from documentation-that-exists-somewhere — the inference that the disclosure will actually reach the consumer holds only when the artifact is portable and fixed at the boundary the data crosses, not merely when the information exists.

knowledge_transfer:
Within ML data governance the data card transfers *as a practice*, its schema-plus-boundary-placement apparatus carrying intact. It moves without translation across dataset publication and its near sibling the **Model Card** (Mitchell et al.) — and the parallel **System Card** — all of which apply the *same* move: a fixed schema enumerating the axes any artifact must be characterized on, mechanically attached at the publication boundary, written to be read before reuse, so the boundary conditions arrive at the same instant as the artifact. A producer documenting a dataset and a producer documenting a trained model run the *same* checklist logic, surface representational gaps the *same* way, and let a consumer read suitability off the *same* standardized fields before training rather than after deployment. Hugging Face's operationalization of both as structured hub metadata is this practice routinized. This is genuine within-domain practice transfer.

Into *adjacent* data-publishing settings — research data repositories (ICPSR, Dryad), government open-data portals, medical-imaging registries, corporate data catalogs — the card form is widely adopted, but the honest reading is **shared abstract mechanism (B)**: what does the structural work there is not anything the card *adds*, but the more general primitives it composes — **metadata** (description on a common axis set), **interface documentation** (boundary conditions stated at the point of crossing), and **`provenance`** (origin and custody of the artifact). The card bundles these and fixes them at the publication boundary, but a research repository's deposit form or a data catalog's required-fields schema is doing the same job through the same primitives; the cross-setting "transfer" is co-adoption of metadata-plus-provenance discipline, not the card mechanism generalizing. Strip the jargon and the data card is "a structured metadata schema attached at a publication boundary describing motivation, composition, and limitations" — already covered by metadata + interface documentation + provenance.

There is, however, a genuine cross-domain recurrence worth naming honestly, and it lives at the level of the *form*, not the ML content. The "card" pattern — *a small, schematized, portable disclosure mechanically attached to an artifact at the boundary it crosses, written to be read before use* — recurs as real co-instances far beyond data: the electronics datasheet that is the literal ancestor (Gebru et al.'s explicit analogy), the nutrition-facts label, the pharmaceutical package insert, the GDPR cookie banner, the model and system cards. These share the disclosure-at-the-boundary structure, and the seed flags a candidate emergent prime — *schematized boundary-disclosure card* — that would house them. That general form, together with the metadata/provenance primes, is what should carry any cross-domain lesson; "data card," as named, is the ML-dataset instance, institutionally specific to ML data governance and adjacent data-publishing fields, and its particular axis set (composition, collection, recommended-and-out-of-scope uses, consent, known confounds) does not itself travel (see *Structural Core vs. Domain Accent*).


Data Class

one_liner: Flag an object-oriented class that holds fields with getters and setters but no domain methods as a symptom that its behavior migrated outward into consumers, then resolve the verdict with one role question — should this class enforce its own invariants?

core_idea:
A data class is an object-oriented code smell in which a class holds fields and exposes them via getters and setters but contains no methods that perform meaningful domain operations — the behavior that belongs to the class has migrated outward and lives instead in the classes that consume it. The object-oriented organizing principle being violated is encapsulation: a class should bundle data and the operations on that data together, enforcing its own invariants so that consumers can rely on them without re-deriving them. A data class inverts this: the fields are exposed, the invariants are nowhere enforced, and each consumer independently implements whatever operations it needs on the class's data. The class becomes a passive record container — a struct wearing object syntax.

The structural consequences compound with the number of consumers. A change to the data layout requires finding and updating every consumer that reached directly into the fields; the class itself offers no stable behavioral surface to hide behind. Validation logic that should be centralized in the class's own methods is instead duplicated across consumers, each duplicating the logic slightly differently, so the same data can be in inconsistent states depending on which consumer last touched it. The class accumulates getters and setters but never acquires methods that express domain concepts — a pattern Martin Fowler catalogs as a code smell in *Refactoring*, with the canonical remedy being Move Method: identify behavior scattered across consumers that properly belongs to the class and move it in, until the class has a behavioral surface commensurate with its data.

The diagnostic question that separates this anti-pattern from legitimate usage is whether the class *should* be enforcing invariants on its own data. If the answer is yes — if the data represents a domain entity with meaningful constraints, state transitions, or business rules — then the class is anaemic and the behavior should move in. If the answer is no — if the class is an intentional pure-data record with no behavioral logic, meant to be constructed once and read — then it is not an anti-pattern but a deliberate value object, and modern language features exist to signal this intent explicitly: Java `record`, Kotlin `data class`, C# `record struct`, Python `@dataclass`. These constructs declare immutability or value-equality semantics and remove the getters-and-setters ceremony; the same surface that is a smell in an entity class is a feature in a deliberate value object. The data class smell is therefore not about the presence of fields but about the mismatch between the class's role as a domain entity and its absence of the behavior that role implies.

scope_of_application:
The data-class smell lives within object-oriented software design, across the subfields that share encapsulation as their explicit organizing principle; its reach is bounded to that paradigm, because the verdict that separating data from operations is a *defect* only holds where the class was expected to bundle them — outside OO the same separation is the default, and the genuine cross-domain echoes belong to the encapsulation/coupling primes and the separation-of-knowledge-from-action family, not here.

- **Object-oriented design proper** — Java/C# beans with only getters and setters and no domain methods; the everyday review target where the smell is named and caught.
- **Layered enterprise architecture** — the same condition appears as the "Anaemic Domain Model" critique, where service layers hold the behavior that should sit on the entities.
- **Domain-Driven Design** — a central concern, with rich invariant-owning aggregates as the contrasting target the smell warns you have failed to build.
- **Refactoring practice** — a catalogued code smell in Fowler's *Refactoring*, sitting beside its encapsulation-and-coupling siblings (Feature Envy, Inappropriate Intimacy, Shotgun Surgery) and resolved by Move Method.
- **Modern value-object language features** — Java `record`, Kotlin `data class`, C# `record struct`, and Python `@dataclass` are where the no-behavior case is deliberately *legitimized*, formalizing the same surface as intent rather than as a smell.

structural_signature:
**Sig role-phrases:**

- **the accessor-only class** — a class exposing fields via getters and setters but holding no domain methods (a struct wearing object syntax)
- **the violated encapsulation** — the expectation that data and the operations maintaining its invariants travel together, here broken
- **the dispersed consumers** — the classes that reached the behavior outward, each independently implementing operations that should belong to the class
- **the unenforced invariants** — constraints nowhere centralized, so validation is duplicated across consumers and the data drifts into inconsistent states
- **the role question** — the one binary the syntax cannot answer: should this class be enforcing invariants on its own data?
- **the anaemic-entity verdict** — yes-branch: a domain entity missing its behavior; the smell is a real defect
- **the deliberate-record verdict** — no-branch: an intentional pure-data value object; the identical surface is a feature
- **the Move Method remedy** — the fix for the anaemic branch: trace dispersed operations back to the data and relocate them in
- **the formalization remedy** — the fix for the record branch: declare immutability/value-equality (Java `record`, `@dataclass`) to signal intent
- **the consumer-count cost** — change cost scales with the number of consumers reaching directly into the fields

what_it_is_not:
- **Not every accessor-only class.** A deliberate value object — fields, getters, no behavior — has a byte-for-byte identical surface and is perfectly correct. The smell is not the shape but the *mismatch* between a class's role as a domain entity and its missing behavior; condemning every class that lacks methods wrongly flags honest records.
- **Not "the class is too simple."** A data class is a *symptom* whose cause is offstage: the behavior that belongs to it has not vanished from the system, it migrated outward into the consumers, where validation logic is now duplicated and quietly diverging. The defect is dispersed, not local — the thin class is the signal, not the whole problem.
- **Not merely "a class with fields."** Holding data is not the offense — every object holds state. The smell is the *absence of the operations that maintain that data's invariants*, so the class cannot vouch for its own consistency. Reaching for "it has too many fields" mistakes the data for the defect.
- **Not a universal anti-pattern.** The verdict is relative to encapsulation, an object-oriented commitment. In functional programming, the relational model, and dataflow systems, separating data from the operations over it is the default and *correct* arrangement — nothing migrated, nothing is wrong. Calling that separation a data-class smell imports an expectation those paradigms never made.
- **Not fixed by switching to a record type.** Java `record`, Kotlin `data class`, C# `record struct`, and Python `@dataclass` do not make a genuine smell disappear — they *declare* that the no-behavior case was intended all along. For an anaemic entity the remedy is the opposite: Move Method, pulling the dispersed behavior back in until the class earns its data.

clarity:
Naming the data class smell makes a verdict legible that the source code itself hides: two classes with the *same* syntactic surface — fields, getters and setters, no behavior — can warrant opposite judgments, and the name forces the reviewer to decide which one is in front of them. A deliberate value object and an accidental anaemic entity are indistinguishable by shape; what separates them is a question the syntax cannot answer on its own — *should this class be enforcing invariants on its own data?* If yes, the class is anaemic and the missing behavior is a defect to be moved in; if no, it is a legitimate record to be formalized as such. Without the concept, a reviewer either flags every accessor-only class (and wrongly condemns honest value objects) or excuses them all (and lets domain logic leak); with it, the smell points to the *one* diagnostic that resolves the case.

The frame also relocates where the practitioner looks for the problem. A data class is a symptom whose cause is offstage: the behavior that belongs to it is not absent from the system, it has *migrated outward* into the consumers, which is why the class looks innocently thin while validation logic quietly duplicates and diverges across the codebase. Recognizing the smell reframes "this class is too simple" into the sharper "where did this class's behavior go, and is it now scattered and inconsistent?" — which is exactly the question the Move Method remedy answers, by tracing dispersed operations back to the data they act on. It separates the real failure (the mismatch between an entity's role and its missing behavior) from a non-issue (the mere presence of fields), so that the modern record/`data class`/`@dataclass` constructs are read correctly: not as a way to make the smell go away, but as a way to *declare* that the no-behavior case was intended all along.

manages_complexity:
A large object-oriented codebase presents a reviewer with thousands of classes and an open-ended worry: somewhere in this system, domain behavior has drifted away from the data it acts on, validation is being duplicated and quietly diverging, and a change to one record's layout will ripple through every consumer that reached into it. Tracking that worry directly would mean auditing every class against every consumer to reconstruct where each operation lives and whether the data's invariants are enforced anywhere — an inspection that scales with the cross-product of classes and call sites. The data-class smell compresses that audit to a single recognizable shape: a class that is all fields, getters, and setters and no domain methods. Spotting that shape lets the reviewer stop scanning behavior across the whole system and localize the candidate failure to one class's surface — the smell is the cheap, local signal that the expensive, dispersed condition (scattered behavior, duplicated invariants, change cost that grows with consumer count) may be present.

But the shape alone is ambiguous — a deliberate value object and an anaemic entity are byte-for-byte indistinguishable in syntax — so the second move is what does the real compression: it collapses the verdict to one binary parameter. *Should this class be enforcing invariants on its own data?* Yes routes to "anaemic — move the behavior in" (Move Method, traced back along the consumers that hold the dispersed operations); no routes to "deliberate record — formalize it" (Java `record`, `@dataclass`, value-equality, immutability). Every downstream consequence — whether the duplicated validation is a defect or a non-issue, whether the missing methods are a hole or by design, whether the modern record constructs are a fix or a declaration of original intent — is read off that single answer rather than re-derived per class. So instead of holding the full behavior-to-data map of the codebase in mind, the practitioner tracks two things: a local syntactic shape (accessor-only class) and one role question (entity or record), and reads the refactoring verdict and its severity off their combination. A diffuse, system-wide complexity ("where did all the behavior go, and is the data ever vouched for?") collapses to a per-class smell plus a one-bit branch.

abstract_reasoning:
The data-class smell licenses a compact reasoning routine for OO code review, built on a local syntactic signature, a single role-question that resolves an irreducible ambiguity, and a remedy keyed to the answer.

*Diagnostic — read a thin class as the symptom of behavior that migrated offstage.* The defining move treats an accessor-only class not as a self-contained simplicity but as a symptom whose cause is elsewhere. Spotting the shape — fields, getters and setters, no domain methods — the reviewer reasons FROM the class's innocent thinness TO a dispersed condition in the consumers: the behavior that belongs to the class has *migrated outward*, so validation logic is being duplicated across consumers and quietly diverging, and the same data can sit in inconsistent states depending on which consumer last touched it. The smell is the cheap, *local* signal that an expensive, *distributed* defect may be present, so the reviewer stops auditing behavior across the whole system and localizes the candidate failure to one class's surface. The inference reframes the lazy observation "this class is too simple" into the sharp "where did this class's behavior go, and is it now scattered and inconsistent?"

*Boundary-drawing — resolve a syntactically-undecidable verdict with one role question.* The characteristic move confronts an ambiguity the source code cannot settle: a deliberate value object and an accidental anaemic entity have *byte-for-byte identical* surfaces, so shape alone yields no verdict. The reviewer draws the line with a single binary the syntax cannot answer — *should this class be enforcing invariants on its own data?* Yes means the class is anaemic, a domain entity missing the behavior its role implies, and the smell is a real defect; no means it is an intentional pure-data record, and the identical surface is a feature, not a smell. This boundary is what stops the reviewer from the two failure modes the unaided eye falls into — condemning every accessor-only class (wrongly flagging honest value objects) or excusing them all (letting domain logic leak) — and it correctly reads the modern record constructs (Java `record`, Kotlin `data class`, C# `record struct`, Python `@dataclass`) as a way to *declare* the no-behavior case was intended, not as a way to make a genuine smell disappear.

*Interventionist — route to a remedy by the role answer, and trace it back along the consumers.* The two branches dictate two different actions, each predicted to fix the corresponding condition. The "anaemic entity" branch routes to Move Method: the reviewer reasons backward from the dispersed operations in the consumers to the data they act on, relocating that behavior into the class until it has a behavioral surface commensurate with its data — and predicts that centralizing the operations collapses the duplicated, diverging validation into one place that enforces the invariant. The "deliberate record" branch routes to formalization: declare immutability and value-equality with a record construct and remove the getters-and-setters ceremony, predicting that this signals intent so future reviewers stop mistaking the record for an anaemic entity. The reviewer selects the remedy by the one role answer rather than reasoning about each scattered call site from scratch.

*Predictive — read change-cost and severity off the consumer count and the role answer.* From the smell plus its branch the reviewer predicts the maintenance consequences before they bite. For an anaemic entity, change cost is predicted to scale with the number of consumers: because each reaches directly into the fields and the class offers no stable behavioral surface to hide behind, a change to the data layout forces finding and updating every consumer in lockstep, and the duplicated validation is predicted to drift further with each independent edit. For a deliberate record, the same surface is predicted to carry none of these costs, because no behavior was ever supposed to live there. So the reviewer reads both the refactoring verdict and its severity off two cheap inputs — the local accessor-only shape and the one-bit role question — rather than reconstructing the full behavior-to-data map of the codebase.

knowledge_transfer:
Within object-oriented software the data-class smell transfers *as mechanism*. The diagnostic (spot the accessor-only shape, then ask the one role question — should this class enforce invariants on its own data?), the verdict branch (anaemic entity versus deliberate value object), and the remedies (Move Method to pull dispersed behavior back in; or formalize with Java `record`, Kotlin `data class`, C# `record struct`, Python `@dataclass`) carry intact across the OO subfields that share encapsulation as their explicit organizing principle. They apply unchanged to enterprise-layered architectures (where the same condition is named the "anaemic domain model"), to Domain-Driven Design (where rich invariant-owning objects are the contrasting target), and to refactoring practice generally, sitting alongside its sibling smells — Feature Envy, Inappropriate Intimacy, Shotgun Surgery — that share the same encapsulation-and-coupling substrate. The transfer is mechanical rather than analogical here because all of these run on the same paradigmatic commitment: a class *ought* to bundle data with the operations that maintain its invariants, so the absence of that bundling is a real, locatable defect with a known cause (behavior migrated outward) and a known fix.

Beyond the OO paradigm the concept does *not* transfer even as a failure — and saying so honestly is the whole point. The data-class smell is a verdict relative to a specific commitment, and where that commitment is absent the "anti-pattern" simply is not one. In functional programming (data types and the functions over them are deliberately separate), in the relational model (tables and queries are separate by design), and in dataflow or pipe-and-filter systems, separating data from operations is the *default and correct* arrangement, not a smell; there is no behavior that "should have" lived with the data, so nothing has migrated and nothing is wrong. This makes the cross-domain situation an instructive instance of case (B): what genuinely recurs across substrates is not "data class" but the *parent* structures the smell instantiates — the absence of `encapsulation` (state and the operations that guard it are pulled apart) and the resulting `coupling` (consumers depend on internal structure, so a layout change ripples through all of them), typically with low `cohesion`. Those primes travel; the OO verdict that the separation is a *defect* does not, because the verdict depends on a paradigm-local expectation. The cross-domain echoes the source gestures at — organizations separating knowledge from decision rights, law separating fact from procedure, pedagogy separating content from feedback — are real and worth studying, but they belong to a separate *separation-of-knowledge-from-action* family, not to "data class"; calling any of them a data-class smell borrows the shape while importing an encapsulation expectation those domains never made, which is analogy, and a misleading one. The honest lesson to carry across domains is the parent (encapsulation/coupling/cohesion, or the knowledge-action separation family where that is the real subject), not the named code smell, whose load-bearing content — that the separation is *wrong* — is OO-paradigm furniture that does not and should not travel. (See *Structural Core vs. Domain Accent*.)


Data Extraction Through Prompting

one_liner: The AI-security failure mode in which an adversary crafts inputs that make a deployed language model emit private content — training text, system prompts, retrieved documents — by exploiting the legitimate inference interface, whose breadth exceeds the access-control envelope around the data.

core_idea: Data extraction through prompting is the AI-security failure mode in which an adversary crafts inputs to a deployed language model that cause it to emit information the operator intended to remain private — verbatim training-set text, memorised personally identifiable information, system-prompt instructions, the contents of retrieval-augmented documents, or upstream API credentials — by exploiting the model's legitimate inference interface rather than by breaching storage systems or model weights. The structural feature that makes this possible is the absence of an enforceable boundary inside the model between what it has internalised or been instructed with and what it is willing to output: the same generation mechanism that produces helpful responses can, under adversarially designed inputs, produce emissions of content the operator intended to withhold. Named techniques instantiate this structure in different ways. Training-data extraction via repetitive or divergence-eliciting prompts — demonstrated by Nicholas Carlini and colleagues against production language models, including the "poem poem poem" attack that recovered verbatim training text — exploits the fact that frequently repeated training samples are more easily reconstructed from model activations. System-prompt leakage via role-play, summarisation, or recursive instruction attacks exploits the model's tendency to treat system-context text as content it can reason about and paraphrase. Prompt injection embeds a "reveal" or "ignore previous instructions" directive inside retrieved documents, web pages, or tool outputs that the model processes as authoritative context, causing it to follow the injected instruction rather than the operator's original instructions. The shared structure across all variants is that the query interface is broader in what it can be made to emit than the access-control envelope the operator has placed around the data: the model's capacity to generate responses conditioned on its full context — training data, system prompt, retrieved documents — is what creates the exfiltration surface, and that capacity cannot be selectively disabled for adversarial inputs without degrading legitimate function.

scope_of_application:
Data extraction through prompting lives across the subfields of AI security and red-teaming; its reach is within LLM-substrate information-disclosure security, bounded by the crafted-prompt techniques and the in-a-generation-model fact that there is no internal boundary between what the model may know and may say. The legitimate-output-channel-leaks-protected-information shape it instances travels under `side_channel_attack` (with `access_control`/`trust_boundary`/`query_interface`); a hardware timing leak or a moderation-policy leak is that shape in another substrate — not a "prompting" attack — and stays out of the map.

- **LLM red-teaming** — training-data-extraction benchmarks (Carlini et al., the poem-poem-poem divergence attack) and the OWASP LLM Top-10 "Sensitive Information Disclosure" and "Prompt Injection" categories.
- **Deployed-product security** — customer-support assistants leaking internal documents, employee chatbots leaking salary data, and RAG systems leaking vector-store contents under crafted prompts.
- **Agent and tool-use security** — prompt injection in retrieved content tricking an agent with file or API access into exfiltrating those resources to an attacker channel.
- **Model-IP protection** — recovery of system prompts or behavioural cloning of proprietary models through the inference interface revealing more than intended.
- **Regulated-deployment compliance** — guarding against PHI extraction under HIPAA, MNPI leakage in finance, and classified-content elicitation in defense, where the same interface-versus-envelope gap is the threat.

structural_signature:
**Sig role-phrases:**

- **the deployed model** — the trained model that has internalised training data, system instructions, or retrieved content the operator intends to keep private
- **the query interface** — the legitimate inference channel accepting adversary-crafted prompts and returning adversary-readable responses
- **the access-control envelope** — the boundary the operator has drawn around the data, narrower than what the interface can be induced to emit
- **the no-internal-boundary fact** — the structural absence of any enforceable line inside the model between what it is permitted to *know* and what it is permitted to *say*
- **the crafted prompt** — the adversarial input exploiting divergence/repetition, role-play, recursion, or injected instructions to elicit protected content
- **the emission** — the protected content (verbatim training text, PII, system prompt, retrieved documents, credentials) carried back out through the sanctioned output channel
- **the query-chaining move** — the attacker triangulating protected content across turns, since each query reveals more than intended
- **the structural irreducibility** — the gap being uncloseable because the conditioning capacity that creates it is the same capacity the helpful behaviour depends on
- **the defense locus** — output filtering, retrieval-source gating, and training-data sanitisation (not the refusal-and-policy layer where jailbreak defenses live)

what_it_is_not:
- **Not a storage breach.** No system is broken into: the weights, the vector store, and the API credentials remain intact, and the leak occurs through the model's *ordinary, sanctioned generation* at the inference interface. Modeling the threat as a storage-security problem — encrypt, lock down, gate — misses where the disclosure actually happens, which is the query interface emitting content the operator meant to withhold.
- **Not a patchable bug.** The gap between what the model is permitted to *know* and what it can be induced to *say* is structural, not a defect awaiting a fix. The capacity to condition responses on training data, system prompt, and retrieved context is the same capacity the helpful behaviour depends on, so it cannot be selectively disabled for adversarial inputs without degrading legitimate function — "switch it off for attackers" is infeasible by construction, not merely unimplemented.
- **Not jailbreaking.** Despite the frequent conflation, this is about information *disclosure*, not the bypass of a behaviour policy; a jailbreak can be the *vehicle* for extraction but is a different failure mode with a different defense locus. Hardening the refusal-and-policy layer where jailbreak defenses live leaves the exfiltration surface — output filtering, retrieval-source gating, training-data sanitisation — untouched.
- **Not closable by an output blocklist.** Because the space of crafted inputs is open-ended, any enumerated list of known techniques (divergence prompts, role-play, "ignore previous instructions") will be evaded by novel inputs; the honest answer to "what can the model be made to say about everything it has access to?" is essentially *anything, modulo cost*. The surface can be narrowed but not closed, so a defense premised on exhausting the attack catalogue is structurally incomplete.
- **Not the model choosing to leak.** The disclosure is not a misbehaving intent or an alignment lapse the model elected; it follows from the *absence of an enforceable internal boundary* between internalised/instructed content and permitted output. Reading it as the model "deciding" to reveal secrets mislocates the cause in the model's disposition rather than in the structural fact that its generation channel is broader than the access-control envelope around its data.

clarity:
Naming this failure mode relocates the data-privacy question from where security engineers instinctively look. The reflex is to treat private data as a *storage* problem — encrypt the weights, lock down the vector store, gate the API credentials — but extraction through prompting shows the leak occurs at the *inference interface*, through the model's ordinary, sanctioned generation behaviour, with no storage system breached. The clarifying move is to make explicit that the access-control envelope an operator has drawn around the data is narrower than the set of things the query interface can be induced to emit, and that this gap is structural rather than a bug to be patched: the very capacity to condition responses on training data, system prompt, and retrieved context is what the helpful behaviour depends on, so it cannot be selectively switched off for adversarial inputs without degrading legitimate function. The sharper question a defender can now ask is not "is this data stored securely?" but "what can the model be made to say about everything it has access to?" — and the honest answer reframes the threat model entirely.

The concept also earns its keep by separating extraction from the sibling failure modes it is constantly conflated with, because the diagnostic boundary dictates where the defense must live. It is not jailbreaking, which bypasses a behaviour policy; extraction is about information *disclosure*, even though a jailbreak can be the vehicle for it. It is not data poisoning, which corrupts training inputs to alter future behaviour; extraction *recovers* inputs after the fact. It is not membership inference, which only establishes whether a record was in the training set; extraction reproduces the record itself. Holding these apart tells the practitioner that extraction defenses belong at output filtering, retrieval-source gating, and training-data sanitisation — not at the refusal-training and policy-classification layer where jailbreak defenses live — so that an operator who hardens only the refusal layer has left the exfiltration surface open.

manages_complexity: The attack surface, enumerated, is unbounded and ever-growing: divergence prompts that recover verbatim training text, role-play and summarisation tricks that leak a system prompt, recursive "ignore previous instructions" directives, injected commands buried in retrieved documents or tool outputs, and an open-ended space of future crafted inputs no blocklist can exhaust — each a separate exploit with its own mechanics. Naming data extraction through prompting collapses that catalogue onto a single structural invariant: the query interface is broader in what it can be induced to emit than the access-control envelope drawn around the data, because the model has no internal boundary between what it is permitted to *know* and what it is permitted to *say*. The defender then stops chasing each technique and tracks one gap, asking one diagnostic question — "what can the model be made to say about everything it has access to?" — whose answer (essentially anything, modulo cost) is read straight off the invariant rather than re-derived per exploit. That same collapse fixes the other load-bearing parameters cheaply. It locates the leak: not at storage (weights, vector store, credentials) but at the inference interface, so encryption and lockdown are seen to miss it before they are tried. It tells the defender the gap is structural, not a patchable bug, because the conditioning capacity that creates it is the same one the helpful behaviour needs — so "disable it for adversarial inputs" is recognised as infeasible up front. And it sorts the defense by a clean boundary against the sibling failure modes it is confused with (jailbreak = policy bypass, poisoning = corrupting inputs, membership inference = mere presence), which places extraction defenses at output filtering, retrieval-source gating, and training-data sanitisation rather than the refusal layer. An unbounded zoo of prompts and a tangle of adjacent threats reduce to one interface-versus-envelope gap, one diagnostic, and a fixed defense locus — from which the threat model, its irreducibility, and where to defend all follow.

abstract_reasoning:
Within AI security and red-teaming the concept licenses reasoning moves that all run on the gap between the access-control envelope and the breadth of the query interface.

*Diagnostic — when private content surfaces, infer that the leak is at the inference interface, and classify which failure mode produced it.* The signature move resists the storage reflex: confronted with a model emitting a verbatim training passage, a salary figure, or its own system prompt, the analyst reasons FROM "no storage system was breached — the weights, vector store, and credentials are intact" TO "the disclosure occurred through ordinary sanctioned generation, conditioned on context the operator meant to withhold." A second diagnostic move reads the emission's *character* back to a technique: a divergence-eliciting or repetitive prompt that recovers exact training text implicates training-data extraction (and points to a frequently repeated, more-easily-reconstructed sample); a role-play or summarisation prompt that paraphrases hidden instructions implicates system-prompt leakage; a "reveal" or "ignore previous instructions" directive followed from inside a retrieved document implicates prompt injection. The reasoning is FROM the observed leak and the input that caused it TO the interface as the locus and the specific variant at work — which a generic "data was exposed" verdict cannot supply.

*Interventionist — place the defense at the locus the gap dictates, and predict what each control will and will not close.* Because the leak lives at the inference interface, the move is to prescribe controls there and predict their reach: output filtering, retrieval-source gating, and training-data sanitisation are the levers, and the analyst reasons FROM "the exfiltration surface is the model's conditioning on training data, system prompt, and retrieved context" TO "harden these output and input-context layers, not the refusal-and-policy layer where jailbreak defenses live." The sharper interventionist prediction is *negative*: reasoning FROM "the conditioning capacity that creates the gap is the same capacity the helpful behaviour depends on" TO "it cannot be selectively disabled for adversarial inputs without degrading legitimate function," so the analyst predicts that any 'patch' aiming to switch off the capacity will fail, and that an operator who hardens only the refusal layer leaves the exfiltration surface open. The move is FROM the structural locus TO a defense placement plus a forecast of its limits.

*Boundary-drawing — separate extraction from its sibling failure modes, and permitted-to-know from permitted-to-say.* A first boundary move holds extraction distinct from the threats it is constantly conflated with, because the distinction dictates where the defense must live: it is not jailbreaking (a behaviour-policy bypass, though a jailbreak can be the *vehicle* for disclosure), not data poisoning (which corrupts inputs to alter future behaviour, whereas extraction *recovers* inputs after the fact), not membership inference (which only establishes whether a record was present, whereas extraction reproduces the record itself). The analyst reasons FROM the signature of the attack TO its category TO the matching defense locus. A second, deeper boundary move names the structural fact the model lacks: there is no enforceable internal boundary between what the model is permitted to *know* and what it is permitted to *say*, so the analyst reasons FROM "the access-control envelope is narrower than what the query interface can be induced to emit" TO "this gap is structural, not a bug" — refusing to model the problem as a closable defect.

*Predictive — anticipate query-chaining and the residual surface no blocklist exhausts.* A forward move predicts adversary behaviour across turns: because the interface reveals more than intended per query, an attacker can chain queries to triangulate protected content, so the analyst forecasts multi-query exfiltration rather than single-shot leaks and sizes defenses accordingly. A second predictive move concerns coverage: because the space of crafted inputs is open-ended, the analyst predicts that any enumerated blocklist of known techniques will be evaded by novel inputs, and that the honest answer to "what can the model be made to say about everything it has access to?" is essentially *anything, modulo cost* — so the defender reasons FROM the unbounded input space TO the conclusion that the surface can be narrowed but not closed.

knowledge_transfer:
Within AI security and red-teaming the concept transfers *as mechanism*, intact. The interface-versus-envelope gap, the storage-reflex-refusing diagnostic, the emission-character-to-technique classification, the defense-locus prescription (output filtering, retrieval-source gating, training-data sanitisation rather than the refusal layer), and the negative prediction (the conditioning capacity cannot be selectively disabled) all carry without translation across the home substrate: LLM red-teaming (training-data-extraction benchmarks, the OWASP LLM Top-10 categories), deployed-product security (support assistants leaking internal docs, employee chatbots leaking salary data, RAG systems leaking vector-store contents), agent and tool-use security (prompt injection in retrieved content exfiltrating file or API resources), model-IP protection, and regulated-deployment compliance (PHI under HIPAA, MNPI in finance, classified content in defense). Across these the data and the deployment change but the structure, the diagnostic, and the defense placement do not; the home domain is LLM-substrate information-disclosure security as a whole.

Beyond the LLM substrate the right reading is the **shared abstract mechanism**, not "data extraction through prompting" travelling. Stripped of model vocabulary the pattern is `side_channel_attack`: a *legitimate output channel of a system reveals information the access-control model intended to protect*, decomposed as side-channel + query-interface-as-attack-surface + a trust-boundary violation between intended and hostile use (`access_control`, `trust_boundary`, `query_interface`). That pattern genuinely recurs as co-instances across substrates with no prompting in them: timing, power-analysis, cache-timing, and electromagnetic-emanation attacks in hardware security; traffic analysis in networking; conversation patterning in social engineering; query patterning that defeats differential privacy; a biometric system leaking template information through false-accept patterns; a content-moderation system leaking its policy through which queries get blocked; a routing system leaking map data through its path choices. All are side-channel extraction — and crucially, *none of them would be called "extraction through prompting."* That is exactly the tell that the LLM case is a new **substrate** for an old pattern, not a structure that itself ports: what travels is side-channel reasoning, and the cross-domain lesson should carry `side_channel_attack` (with `access_control`/`trust_boundary`/`query_interface`), not the prompt-specific construct. The home-bound cargo is everything LLM-particular: the crafted-prompt techniques (divergence/repetition like the poem-poem-poem attack, role-play and summarisation system-prompt leakage, recursive "ignore previous instructions," prompt injection inside retrieved context), the structural fact realized *in a generation model* that there is no internal boundary between what it is permitted to know and to say, and the specific defense surfaces tuned to that substrate. Naming a hardware timing leak or a moderation-policy leak a "prompting" attack would be **analogy**; the honest move is to treat LLM extraction as the worked AI-substrate instance of `side_channel_attack` and carry that prime across domains. See *Structural Core vs. Domain Accent*.


Data Lineage

one_liner: Recording, for every data element, the complete sequence of sources, transformations, and movements that produced it — as edges in a queryable dependency graph — so audit questions become forward and backward traversals rather than forensic reconstruction.

core_idea:
Data lineage is the discipline of recording, for every data element in a system, the complete sequence of sources, transformations, and movements that produced its current value — together with the agents and times responsible at each step — in a form that supports bidirectional traversal of the resulting dependency graph. Given any data element, lineage infrastructure allows backward traversal to all upstream sources it transitively depends on and forward traversal to all downstream consumers it transitively feeds. The substrate is information flowing through a directed acyclic graph (or near-DAG) of processing nodes: ETL pipelines, joins, aggregations, model training runs, dashboard computations.

The structural commitment that distinguishes data lineage from generic documentation or logging is *queryable graph topology*: provenance is not recorded as a flat audit log but as edges in a dependency graph, so change-impact analysis becomes a forward-reachability query from a changed source, root-cause analysis becomes a backward-traversal from a failing output, and blast-radius assessment becomes a reachability computation. Without lineage, the same operations require forensic reconstruction across heterogeneous codebases. The practical payoff is asymmetric: a bad dashboard number with full lineage resolves in minutes through graph traversal; without lineage it is archaeological work that may take days or never complete. Regulatory frameworks including BCBS 239, GDPR, and FDA data-integrity requirements encode this need as mandatory traceable provenance for regulated metrics back to source data. Tooling ecosystems — OpenLineage, Apache Atlas, dbt lineage views, Marquez — have converged on a shared graph model for representing these dependencies across heterogeneous pipeline technologies.

scope_of_application:
Data lineage lives within data engineering — wherever information flows through a directed (near-DAG) graph of transforming processes whose provenance can be recorded as queryable graph topology; its reach is within that substrate, since the discipline needs transforming nodes whose edges can be walked. The substrate-neutral residue ("trace a derived item to its sources via the derivation graph") belongs to the parent `provenance` / `traceability` primes; the ETL/ML-pipeline toolchain and the name do not travel.

- **Analytics and data warehousing** — the home turf: tracing the path from raw operational tables through staging, fact, and dimension marts to the dashboard tile a stakeholder sees, so a wrong number resolves by backward traversal.
- **Machine-learning pipelines** — recording which training data, code, and hyperparameters produced which model version, for reproducibility and change-impact across model lifecycles.
- **Feature stores** — tracking which upstream sources and transformations feed each served feature, so a changed source's downstream model and serving consumers are enumerable.
- **Regulatory compliance** — BCBS 239, GDPR, and FDA data-integrity requirements encoding mandatory traceable provenance of regulated metrics back to source data.
- **Scientific reproducibility** — recording which raw measurements plus analysis pipeline produced which published figure, so a result's derivation is auditable end to end.
- **Cybersecurity forensics** — reconstructing which input, through which processing nodes, produced an observed corrupted or compromised state.

structural_signature:
**Sig role-phrases:**

- **the data element** — the unit whose derivation history is being recorded and reconstructed
- **the processing graph** — the directed acyclic (or near-DAG) graph of nodes — ETL steps, joins, aggregations, training runs, dashboard computations — whose outputs become other nodes' inputs
- **the transformation record** — at each node, the operation performed plus the agent and time responsible
- **the queryable graph topology** — the commitment that provenance is recorded as edges in a dependency graph rather than a flat audit log, so audits become traversals
- **the backward traversal** — from any element, reaching all upstream sources it transitively depends on (root-cause, derivation soundness)
- **the forward traversal** — from any element, reaching all downstream consumers it transitively feeds (change-impact, blast-radius)
- **the local-cost signature** — audit difficulty set by the depth and fan-out of the dependency graph local to the affected node, not by the total code volume of the system
- **the derivation-grounded quality** — trust as a property of a value *and* its recorded chain of sources, transformations, and refresh times, not of a value in per-snapshot isolation

what_it_is_not:
- **Not a flat audit log.** A chronological record of actions does not encode the transformation *graph*, so it cannot answer reachability questions. What distinguishes data lineage is *queryable graph topology* — provenance recorded as edges in a dependency graph — which is exactly what turns change-impact and root-cause into traversals rather than archaeology.
- **Not generic documentation or logging.** Scattered notes and per-job logs describe steps in isolation; lineage is the single recorded derivation graph over which audit questions become forward and backward traversals. The difference is not how much is written down but whether the dependencies are an explicit, traversable structure.
- **Not versioning.** Versioning tracks successive states of *the same* artifact over time; lineage tracks the *derivation across* artifacts — which sources and transformations produced this value. One follows an artifact's history; the other follows the graph of what fed what.
- **Not a per-snapshot data-quality check.** Quality-as-validation asks "does this table pass its checks right now?" — a property of a value in isolation. Lineage reframes quality as a property of a value *and its derivation*: a plausible-looking number can be untrustworthy because its recorded chain includes a stale or unsound upstream step.
- **Not a measure of system size.** With lineage in place, audit difficulty is set by the depth and fan-out of the dependency graph *local* to the affected node, not by the total code volume — a deep, high-fan-out neighborhood is expensive even in a small system, a shallow one resolves in minutes even in a large one.
- **Not `provenance` or `traceability` as such.** Data lineage is the *data-engineering specialization* of those primes — it adds the substrate restriction that the medium is information flowing through transforming processes (a near-DAG), not artifacts in physical custody or design requirements. The substrate-neutral "trace a derived item to its sources via the derivation graph" belongs to the parents; the ETL/ML-pipeline cargo and the name do not travel.

clarity:
Naming whether a system has data lineage makes legible why some failures are tractable and others are archaeology. A wrong dashboard number is, with lineage, a bounded traversal of a recorded dependency graph — walk backward to the nearest upstream node where the value could have gone bad — and without it, a forensic reconstruction stitched across heterogeneous codebases that may take days or never resolve. The label locates the difference precisely: not in the team's skill or the pipeline's complexity, but in whether provenance was recorded as *queryable graph topology* rather than a flat audit log. That distinction is what separates "we can compute the blast radius of this change" from "we will find out which downstreams broke when they break."

It also sharpens what *data quality* can even mean. Treated per-snapshot, quality collapses to "does this table pass its validation checks right now?" — a property of a value in isolation. Lineage reframes quality as a property of a value *and its derivation*: a number is trustworthy not because it looks reasonable but because the chain of sources, transformations, and refresh times that produced it is known and sound. The sharper questions a practitioner can then ask are reachability questions — given this changed source, what transitively depends on it (forward); given this failing output, which upstream node is the closest possible origin (backward) — questions that are well-posed only once provenance is an explicit graph rather than scattered documentation.

manages_complexity:
A data system without lineage presents its operators with a black box whose every audit question is an open-ended forensic problem. "Which downstreams break if I change this source?" "Where did this wrong number originate?" "What is the blast radius of this incident?" Each, answered from scratch, means reading across heterogeneous codebases — SQL, ETL scripts, model-training jobs, dashboard definitions — and reconstructing by hand which output fed which input, work whose cost scales with the *total code volume* of the system and may take days or never resolve. The questions look distinct and each pipeline looks unique, so the team faces a fresh archaeology for every change and every failure. Data lineage collapses that sprawl by recording provenance once as an explicit dependency graph, after which the entire family of audit questions reduces to three traversal primitives on that single object: change-impact is forward-reachability from a changed source, root-cause is backward-traversal from a failing output, and blast-radius is a reachability computation. The heterogeneous codebases stop mattering as such; what the analyst tracks instead is the graph's topology.

The compression has a precise cost signature. Once provenance is queryable graph topology rather than a flat log or scattered documentation, the difficulty of any audit depends on the *depth and fan-out* of the dependency graph local to the affected node — how many transformations a value passed through, how widely it branches — not on the size of the whole system. A bad dashboard number resolves as a bounded walk backward to the nearest upstream node where the value could have gone wrong, in minutes rather than weeks. And the reframing extends what "data quality" can be tracked as: instead of a per-snapshot property of a value in isolation (does this table pass its checks now?), quality becomes a property of a value together with its derivation, read off the soundness of the recorded chain of sources, transformations, and refresh times. The analyst thus reasons over one well-posed graph and a fixed set of reachability queries, rather than re-deriving each case's history from the raw machinery that produced it.

abstract_reasoning:
Data lineage licenses reasoning moves that treat the data-processing DAG as *the* system model and reduce a family of audit questions to graph traversals on it. The most distinctive is a set of *directional* moves, each mapping an operational question to one traversal primitive. Change-impact reasoning is a *forward* move: from a source about to change, the analyst computes forward-reachability to enumerate every downstream consumer that transitively depends on it, predicting the blast radius of the change before it is made rather than discovering which downstreams broke when they break. Root-cause reasoning is the *backward* move: from a failing output, the analyst walks backward to the nearest upstream node where the value could have gone wrong, narrowing the origin by traversal rather than by reading across heterogeneous codebases. Blast-radius reasoning is a reachability computation over the same graph. The analyst reasons from the *direction* of the question to the direction of the traversal, and each query is well-posed only because provenance is an explicit graph; the move that makes them answerable is recording provenance as queryable graph topology.

A *boundary-drawing* move separates the regime where these failures are tractable from the regime where they are archaeology, and locates the difference precisely. The analyst reasons that a wrong dashboard number is, with lineage, a bounded backward traversal of a recorded dependency graph, and without it a forensic reconstruction stitched across SQL, ETL scripts, model-training jobs, and dashboard definitions that may take days or never resolve — and that the difference lies not in the team's skill or the pipeline's complexity but in whether provenance was recorded as a graph rather than a flat audit log. From this the analyst derives a *cost prediction*: once provenance is queryable topology, the difficulty of any audit depends on the depth and fan-out of the dependency graph *local* to the affected node — how many transformations a value passed through, how widely it branches — not on the total code volume of the system. So the analyst predicts resolution time from local graph shape, and reasons that a deep, high-fan-out neighborhood is the expensive case even in an otherwise small system, while a shallow one resolves in minutes even in a large one.

A further *boundary-drawing* move reframes what "data quality" can mean and thereby what can be reasoned about. Treated per-snapshot, quality is a property of a value in isolation — does this table pass its validation checks right now? The analyst instead reasons about quality as a property of a value *and its derivation*: a number is trustworthy not because it looks reasonable but because the recorded chain of sources, transformations, and refresh times that produced it is known and sound. This converts trust into a backward-traversal verdict — walk the derivation and check each node's operation, agent, and refresh time — and lets the analyst flag a plausible-looking value as untrustworthy when its chain includes a stale or unsound upstream step. The recurring habit the concept installs is to stop asking audit questions of the raw machinery and instead pose them as reachability queries on a single recorded graph: given this changed source, what transitively depends on it; given this failing output, which upstream node is the closest possible origin; and is the derivation behind this value sound end to end.

knowledge_transfer:
Within data engineering the concept transfers *as mechanism*, and the transfer is literal because the substrate is uniform: information flowing through a directed processing graph. The same three traversal primitives (forward-reachability for change-impact, backward-traversal for root-cause, reachability for blast-radius), the same cost signature (resolution time set by the depth and fan-out of the dependency graph local to the affected node, not by total code volume), and the same reframing of data quality (a property of a value *and its recorded derivation*, not of a value in isolation) carry without translation across analytics and warehousing (raw tables through staging, fact, and dimension marts to a dashboard tile), machine-learning pipelines (which training data, code, and hyperparameters produced which model version), feature stores, scientific-reproducibility pipelines, and cybersecurity forensics. The tooling ports too, because the ecosystems (OpenLineage, Apache Atlas, dbt lineage views, Marquez) deliberately converged on one shared graph model across heterogeneous pipeline technologies, and the regulatory drivers (BCBS 239, GDPR, FDA data-integrity) encode the same traceable-provenance requirement. The vocabulary does not strain across these because they are one substrate: transforming processes connected into a near-DAG of data flow.

Beyond data engineering the honest account is a *shared abstract mechanism* — case (B), and an unusually clean one because the generalization is exactly the parent the concept specializes. Strip the data-and-pipeline vocabulary and what remains is "trace any derived item back to its sources, and forward to its consumers, via the derivation graph" — which is just `provenance` (a documented origin-and-custody record) carrying `traceability`'s bidirectional-link commitment. That general pattern genuinely recurs across substrates as *co-instances* wherever the substrate is information moving through transforming processes — financial-instrument trade lineage, document-change lineage, content-pipeline lineage — and there it carries a real, transferable lesson (record provenance as a queryable graph so audit questions become traversals rather than archaeology). What does *not* travel is the data-engineering cargo: the ETL/ML-pipeline DAG, the OpenLineage/Atlas/dbt toolchain, the warehouse-specific transformation records, and the "data lineage" name itself are domain furniture that does not survive extraction. And the transfer has a definite edge: it succeeds only while the substrate really is information flowing through transforming processes, and it *strains* the moment the directed-graph picture goes metaphorical — social influence, political action — where there is no recorded transformation at each node to walk. So the honest move is that the cross-domain reach belongs to the parents (`provenance` and `traceability`), of which data lineage is the data-engineering specialization narrowed by a substrate restriction rather than by any new mechanism; "data lineage," as named, does not float free of the data-processing substrate (see *Structural Core vs. Domain Accent*).