Glossary

Alphabetical, and defined the way the application uses the word — each entry links on to the page that explains it further, where one exists.

• Acceptance criterion — One testable condition under a requirement, numbered against it (REQ-7.AC-1). An expectation can claim to verify one, and coverage is computed from whether one does.
• Access request — A ticket raised against one source system, asking for the access its chosen tables need; raising one is disabled until that system has a section in the data contract v0.1. The system's owner approves or rejects it, never the team that raised it — see source owner.
• Actor and principal — Two names carried on every audit log event. actor is the name the record attributes the action to; principal is who was actually signed in. The two are the same person unless an administrator is acting as a role, and the checks that stop somebody approving their own request always read principal, never actor.
• Administrator — The role with every permission, plus adding people and changing connection settings. A workspace of one person needs it to be usable; a real deployment gives it to as few people as possible. See administrator.
• Audit log — The append-only list of every state change the factory makes: one row per event, with its actor, its principal, and the state it moved from and to. Nothing in it is ever updated or deleted. See Audit events for every code it records.
• Check — see Expectation.
• Contract — see Data agreement.
• Coverage — Which acceptance criteria the live release's expectations actually verify. A criterion with nothing testing it is uncovered; one with a failing expectation is failing — different problems, for different people to fix.
• Data agreement (the contract) — The versioned promise to consumers: the columns that ship, what each one means, how fresh they will be, and what the product is explicitly not for. The use case team accepts it; accepting needs at least one accepted requirement, and closes the agreement gate. See Decision 0001.
• Data contract v0.1 — The first version of a product's data contract, written in Source: one section per source system — which tables, what for, how often, and what is being relied on. Sent to the system's owner and answered on the record; once every system in scope has answered granted or with conditions, and its access request is approved, the approval to load gate closes.
• Data hub — The role that builds the product: the design, the data model, the contract text and the release. It is accountable for the product working, not for whether it was wanted. See data engineer.
• Data model — The shape of the shared layer every product can extend, and the product's own layer on top of it: its grain, which rows count, and how each measure is calculated. A person designs it on the Design the tables page — the modelling agent can propose one, but accepting its proposal does not save it.
• Data product — The thing the factory delivers: a named, owned artefact that moves through nine steps across three phases, from its Data Product Description to a live release, gaining its own requirements, data model, data agreement and releases along the way.
• Data Product Description — What the first step, Define the data product, produces: a short statement of what the data product is for, and what it is explicitly not for. Its anchor and internal name are still brief.
• Data Vault — The modelling style behind the shared layer: a hub registers one business key once, however many systems mention it; a link records that a relationship between two hubs was observed; a satellite hangs descriptive attributes off a hub or a link, so they can change without rewriting either. An agent or a person decides the vault; a generator compiles it to SQL.
• Demand — The code's name for a section of the data contract v0.1, and also the word for the act of sending and answering one: a demand is drafted, sent, then granted, granted with conditions, or denied. A sent demand cannot be re-sent — only answered, or replaced by a new draft or an uploaded version.
• Drift — A computed mismatch between what the data contract or a check assumes and what is now true: a source profile that has moved, a model that no longer matches the agreement, or a warehouse constraint the agreement says is enforced and is not. Detecting it is always arithmetic, never a model's opinion.
• Expectation — One automated data-quality rule inside a data contract — not null, unique, a range, a foreign key, a custom predicate — that compiles to counting the rows that break it. Running one is also called a check; its result is attributed to whichever acceptance criteria it claims to verify.
• Flag — One open instance of drift on the board: a code, a severity, and what to do about it. It is resolved when the condition is gone, or accepted when somebody decided to ship anyway, in writing — an accepted flag still shows, and comes back if the condition gets worse.
• Gate — One of three decisions a phase cannot finish without, each made by somebody outside the team that did the work: approval to load (Source, the source owner), agreement (Refine, the use case team accepting the data agreement) and sign-off (Deliver, a consumer signing the integration test). The phase strip shows a gate as closed only once its whole phase is done.
• MCP — The factory's read-only Model Context Protocol server: five tools (products, search, describe, facet, gaps) that let an agent query the same record a person sees, without writing any of it. Reached on stdio for an agent on the same machine, or over HTTP at /api/v1/mcp for one that is not. See Read API and MCP.
• Mock-up — Something built to a vendor's published interface but never run against a real tenant: pushing a ticket to Azure DevOps or Jira, for instance, which mints its own numbers and marks them simulated until a real organisation is configured. See Push to a tracker.
• Ontology — The semantic layer as one graph: data products, requirements, tables, attributes, glossary terms, systems and owners, and how they connect. It is what the application's Ontology pages draw, and what MCP searches. See GET /ontology.
• Phase — One of the process's three stages — Source, Refine, Deliver — each with one outcome, one document it produces, and the gate that closes it. See Workflow for all three, their steps and their RACI.
• Promotion — Making an approved release live: in one step, it is materialised into production and its data contract is published for consumers to read — as 1.0.0, the first time. The same permission approves, promotes and rolls back a release. See data engineer.
• Proposal — A draft an agent writes — for the requirements, the data model or the data contract — stored with the agent version that produced it. It has no effect until a person accepts it, rejects it, or writes the thing by hand instead; for the data model specifically, accepting does not save it, only the design page does.
• Release — One build of a data product: the SQL it compiles to, and the result of running every expectation against what came out. A release moves through draft, validated (or blocked, if an error-severity check failed), approved, live, and then superseded or rolled back. See data engineer.
• Requirement — A stable, numbered thing a data product must do (REQ-7), carrying an append-only chain of revisions; each revision states what must be true and lists its acceptance criteria. Its status — proposed, accepted, contracted, verified, live, retired — is mostly computed from the rest of the record, not set by hand.
• Revision — Two different things share this word. A requirement's revision is one immutable version of it — editing writes a new one rather than rewriting it. A workflow revision is the version of the process file itself; see Workflow revision.
• Rollback — Promoting an earlier, superseded release back to live. The release being undone keeps the superseded state it already reached — a rollback is a promotion, never a deletion, so what went wrong and when it was undone both stay on the record. See data engineer.
• Scope — The source systems and tables a data product is allowed to be built from. The second step suggests subjects from the brief, matched to the systems that hold them and the words that matched — a suggestion to argue with, never a selection; a person always chooses.
• Service token — A bearer credential issued to a system rather than a person, scoped to read-only access on /api/v1. It is shown once, kept only as its SHA-256 hash, and named for the system that holds it. See Issue an API token.
• Simulated — A demo-only stand-in for a real decision: Simulate the owner's answer and Simulate a signature record one, with a note that nobody was actually asked. A release can never be promoted on a simulated approval — a real decision has to replace it first.
• Source owner — A person holding the source system role for one particular system. Who may answer for a system is checked against that person's own row, not the role in general, so one registered owner cannot grant access to every system. See source owner.
• Source system — The role that owns data somebody wants. It is the only role that can sign a section of the data contract v0.1 or answer an access request for its own system — a role can never approve its own request, so the team that asked is never the team that answers.
• Step — One of the nine units of work inside a phase, three per phase, each one a person, an agent or the application decides. Its state is computed from what already exists in the record rather than stored as a flag.
• The record — Everything the factory keeps, taken together: every document and its versions, every release, every decision, and the audit log that ties them to a time and a name. People read it through the application; systems and agents read it through the read API — one record, two doors.
• Use case team — The role that asks for a data product and lives with what it promises: writes the Data Product Description, states the requirements, and is the only role that can accept the data contract and sign off the integration test. See use case team.
• Version — The factory's own release number, MAJOR.MINOR.PATCH, shown at the foot of the sidebar and on every page of this documentation. Not to be confused with a data product's release or its agreement's version. See Versioning.
• Workflow revision — The exact version of dpf/workflow.yaml a product was built under, recorded as a schema number and a content fingerprint (v1 · a1b2c3…). It changes only when the file the running deployment loads changes, never when a single product moves between steps — a product started under an older one is marked changed since this was started. See Change the workflow.