Specification: Competency Questions and the ORSD

📍 Where we are: Part I · Specification — the first move in the lifecycle. Before a single class is drawn, we write down what the finished ontology must be able to answer. This chapter is the requirements specification the rest of the book is built and judged against.

A common way to start an ontology is to open an editor and begin naming classes. It is the wrong way, and it is worth saying why on the first page. An ontology is a shared, machine-readable vocabulary — a precise set of agreed terms (classes) and the relationships between them that a computer can reason over. But an ontology is not a description of the world — the world is infinite, and you could model a cell down to its atoms or up to the org chart and never stop. An ontology is an instrument built for a purpose, and the purpose is to answer questions. So the discipline that has held up across every serious ontology-engineering methodology since the mid-1990s is the same: start from the questions, write them down, and let every later modeling choice be judged by whether it serves one [1].

The simple version

You don't build a house by buying bricks. You start with a brief: how many bedrooms, who lives here, what must it never do (leak, fall down). Then the brief becomes a blueprint, and at the end an inspector checks the finished house against the brief — room by room — before anyone moves in. A competency question is one line of that brief for an ontology ("can it tell me which batches share this cell bank?"), the ORSD is the whole brief, and this book's validate.py — a small Python script you run from the command line — is the inspector: it runs every line of the brief against the finished model and fails the build if even one is unmet. Requirements first, then the model, then the inspection — never bricks first.

The lifecycle this book follows: NeOn shapes the early phases and the ORSD, SAMOD drives the test-first loop in the middle, and LOT governs publication — with the running antibody campaign carried through every phase. Original diagram by the authors, created with AI assistance.

A note worth planting early, because the rest of the book leans on it: a competency question and the ORSD are themselves information about a physical thing. BFO is the foundational upper ontology this book builds on (Part III); in its terms, the brief is an information content entity (a generically dependent continuant) that is about the independent continuants it governs — the cell bank, the batch, the vial. Keeping the brief (the information) distinct from the thing it describes (the physical lot) — the continuant/information split — is the same separation Parts III–VI build the model on, applied here to the requirements document first.

Three methodologies, one backbone

This book does not invent a process. A methodology here is just an agreed answer to the three questions every ontology project faces — where the requirements come from, how you grow and test the model, and how you publish and keep it alive — and no single published method answers all three equally well. So this book composes the three the field actually uses, each strongest over one stretch of the lifecycle the rest of the book walks. They are complementary, not rival:

• NeOn gives the overall shape and the requirements artifact. The NeOn Methodology (named for the EU NeOn research project) frames ontology building as a set of flexible scenarios — specification, reuse of existing ontologies and resources, conceptualization, formalization — rather than one rigid waterfall, and it is where the Ontology Requirements Specification Document (ORSD) comes from [2]. Part I (this part) and Part II (Reuse) are NeOn's.
• SAMOD — the Simplified Agile Methodology for Ontology Development — gives the rhythm of every modeling chapter: a small, test-first iteration over a "modelet" — write the competency question, model the slice, test it against the data, refactor — repeated until the model is whole [3]. Parts III–VI run on SAMOD's loop.
• LOT — the Linked Open Terms method — gives the back end: publication, versioning, reuse-first authoring, and FAIR release of the finished vocabulary [4]. Part VII is LOT's.

All three share the conviction this chapter opens with, traceable to Grüninger and Fox's founding work and codified for beginners in Ontology Development 101: an ontology's requirements are written as competency questions, and the model is validated by answering them [1][5].

The ORSD: a requirements brief for the model

The ORSD is a short document, agreed before modeling, that fixes what the ontology is for. It has seven parts. Here is ours, for the CHO (Chinese-hamster-ovary cell) monoclonal-antibody (mAb) process this book models end to end — see Book 1 for the physical process.

1. Purpose

Turn one biologic-manufacturing campaign — from the discovery target to the cold-chain vial — into a single, machine-actionable knowledge graph, so that lineage, impact, quality-by-design, and release questions are answerable by query instead of by spreadsheet archaeology.

2. Scope

In scope: the discovery-to-distribution path of one platform CHO mAb (a standardized, reused host-cell-line and process template — swap the antibody, keep the process, which is what lets one brief model the whole campaign) — the physical process Book 1 walks through — genealogy (derivedFrom), critical process parameters and quality attributes and the links between them, the release specification and its gate, viral-clearance summation, serialization and containment, regulatory substance identity, and the provenance of reconciled source records.

Out of scope (named, not forgotten): clinical and patient data; financials and scheduling; real-time process control (the graph documents setpoints, it does not actuate them); a multi-product portfolio; and cross-organization federation beyond the factory wall — which the verdict treats as a genuine limit, not an omission.

3. Intended end-uses

Lineage traceback; recall-impact scoping; CPP→CQA root-cause investigation; release verification; viral-clearance review; packaging track-and-trace; FAIR cataloging; and grounding for retrieval-augmented AI (giving an AI verified facts to answer from).

4. Intended users

QA/QC reviewers, manufacturing-science (MSAT) investigators, regulatory-submission authors, data engineers and ontologists, and the platform/knowledge-graph vendors surveyed in Part VIII.

5. Functional requirements — the competency-question catalog

The functional requirements are the competency questions. There are 23, grouped by the question they answer. Each carries a stable identifier (CQ-01 … CQ-23) used throughout the book, and — this is the point of the whole chapter — each is executable: it maps to a SPARQL query (the query language for graph data — like SQL for a knowledge graph), a SHACL gate (a rule that checks the data is complete and well-formed), or a reasoner check (software that derives new facts the data only implies), and validate.py runs it as a pass/fail test (the next chapter shows the live result).

How each of these was written. A competency question is a single question, written in plain language before any modeling, that the finished ontology must be able to answer. Authoring a good one is a short discipline — traceable to Grüninger and Fox and codified in Ontology Development 101 [1][5] — worth doing in the open with one example, CQ-04:

1. Start from a real scenario, not an abstraction. A drug-product lot fails QC, and the investigator must find every other lot that could share its fault. That happens on the floor, and someone answers it under pressure.
2. Phrase it as one atomic question. When a lot fails, which other products share its lineage? — one question, not three bundled together.
3. Fix the shape of the answer. A set of lot identifiers. Deciding the answer-shape in advance is what makes the question falsifiable: a wrong model returns the wrong set, and you can see it.
4. Read the terms out of the question. Lot, product, lineage, derivedFrom — the nouns and the relation the model will then have to define. The question, written first, is already a specification of what to build.

A question that survives this is well-formed in the Grüninger–Fox sense: atomic, answerable by a single artifact, and falsifiable — and the 23 below are each written to that bar.

These 23 are not abstractions plucked from the air: each group is a question the campaign in the earlier books already forces someone to ask. Lineage and impact are the two halves of a recall — trace one lot back to its origin, and one cell bank forward to everything it touched — the traceability Book 1's cell banking promises. Trajectory and QbD are the deviation questions: where along purification a quality attribute drifted, and which critical process parameter drives it. Release is the QA gate at lot disposition; viral is the clearance dossier's log summation; packaging is the warehouse's aggregation query; provenance is the data steward's reconciliation; characterization is the cell-bank release gate; and units and structural are the data-layer guarantees — a number is never bare, and equipment is never confused with the batch it holds. Every one is a real need the earlier books raise; the ontology's job is to make each answerable by a single query.

The catalog is grouped below by the kind of question it answers, so the CQ numbers do not run in strict order — the numeric sequence CQ-01 … CQ-23 is preserved in cq-catalog.json.

Group	CQ	The question the model must answer
Lineage	CQ-01	Given any downstream material, which materials does it derive from, to any depth?
	CQ-03	What is the originating bioreactor batch of a drug-substance lot, and its release monomer value?
Impact	CQ-02	Given a working cell bank, which materials across the whole campaign descend from it?
	CQ-04	When a drug-product lot fails, which other products share its lineage (siblings via the cell bank)?
Trajectory	CQ-05	What is the in-process HMW-aggregate value at each purification step (where did quality change)?
QbD	CQ-06	Which process parameters affect a given critical quality attribute?
	CQ-07	From a CPP, through its affectsQuality link and the run that realized it, to the released DS lot — does the chain resolve?
Release	CQ-08	Does a released substance lot carry exactly one in-spec value for every required CQA?
	CQ-09	Is a released lot attributably signed, with a status from the controlled set?
	CQ-10	Do the finished product lots meet finish-specific criteria (sterile, appearance, fill volume)?
	CQ-11	Are out-of-spec lots flagged on exactly the failing path and nowhere else?
Viral	CQ-12	What is each orthogonal clearance step's validated LRV, and the summed total clearance?
Packaging	CQ-13	What serialized units are contained, transitively, within a given package?
	CQ-14	Is containment kept distinct from genealogy?
Provenance	CQ-15	Do two source-system records reconcile to one curated decision without an owl:sameAs over-merge?
	CQ-16	Does the ISO IDMP regulatory identity attach to the same node the release gate validated?
Characterization	CQ-17	Is the working cell bank fully characterized, so it conforms to the cell-bank gate?
	CQ-18	Is the working cell bank within its validated passage limit?
Units	CQ-19	Does every stored quantity carry a unit — no bare numbers?
	CQ-20	What host organism, by stable NCBI Taxon IRI (a global web identifier — like a URL — for the species), does the line express its product in?
Structural	CQ-21	Which vessel did a cell-culture run occur in (equipment separated from the batch material)?
	CQ-22	Are the long-range transitive derivedFrom edges inferred, and is equipment inferred a BFO material entity?
	CQ-23	Do the disjointness guards catch planted conflations (a Batch typed as a process, or as a bioreactor)?

Each row of that catalog binds to exactly one decidable artifact and one expected answer-shape — the traceability the ORSD exists to provide. The check.type recorded in cq-catalog.json is the expected-answer type:

Answer shape (check.type)	What it asserts	CQs
row_count	the answer set has a fixed size	CQ-01 (11 rows), CQ-19 (0 rows)
equals / contains	the answer set is exactly / at least a named set	CQ-02, CQ-04, CQ-05, CQ-06, CQ-13, CQ-15
row_match	a specific labelled row is present	CQ-03, CQ-07, CQ-20, CQ-21
ask	a boolean holds (or must not hold)	CQ-09, CQ-14, CQ-16, CQ-18
sum	a column totals a known value	CQ-12 (ΣLRV = 8.7)
SHACL conformance	a closed-world gate passes, or catches a planted error	CQ-08, CQ-10, CQ-11, CQ-17, CQ-23
reasoner closure	an inference was actually derived	CQ-22

This is the well-formedness bar from the top of the section made mechanical: the check.type is the falsifiable answer-shape, so atomicity and single-artifact answerability stop being style notes and become something validate.py enforces.

Two scoping notes the catalog encodes deliberately. The release gate (CQ-08) checks exactly five CQAs — SEC monomer, HMW aggregate, CEX main peak, host-cell protein, and protein concentration; the drug-substance lot also carries residual host-cell DNA (8.0 pg/mg) and endotoxin (0.5 EU/mg), which the dataset records on DS-001 as safety attributes reported on the certificate but keeps out of the five-CQA completeness gate, to match the worked specification Spec-DS-mAb-A. And viral-clearance review (CQ-12) means querying the claimed, validated log-reduction values the graph records for each orthogonal barrier and confirming their sum — low-pH inactivation 4.5 plus virus-retentive nanofiltration 4.2, totalling 8.7 logs — not reconstructing the spiking-study design, which stays in the validation report the graph points at.

6. Non-functional requirements

The qualities the model must have regardless of any single question: grounded (every class sits under BFO); reuse-first (align to public ontologies, mint only what is genuinely local); offline-validatable (validate.py needs no network); tractable (the model stays inside OWL 2 RL — a restricted, fast-to-reason flavour of the OWL ontology language that validate.py reasons in — so the rule-based OWL-RL engine computes a complete closure, every fact the rules can derive worked out once, in polynomial time; derivedFrom is genuinely transitive — if A derives from B and B from C, the reasoner infers A derives from C — a real owl:TransitiveProperty honored by the reasoner, not faked by pre-materializing the lineage chain, and it is deliberately kept out of every cardinality restriction so the transitivity stays description-logic-legal); truthful (every snippet in the book is a real excerpt of the loadable dataset); bilingual (published EN/KO); and FAIR on publication.

7. Pre-glossary

The handful of terms fixed before modeling, so two authors do not coin two words for one thing: Material, Equipment, Quality, Process, Information Artifact, Process Parameter; the relations derivedFrom, affectsQuality, occursIn, contains; and the domain terms CQA, CPP, cell-bank tier (RCB/MCB/WCB — research, master, and working cell bank), LRV (log-reduction value — how many factors of ten of virus a clearance step removes, so 4.5 + 4.2 logs sum to 8.7), IRI (a stable web identifier, like a URL, that names a thing unambiguously so two systems mean the same entity; the NCBI Taxon IRI is the public, resolvable identifier for a species), release status.

A note on what critical means, since the CPP→CQA link is the spine of half these questions. A critical quality attribute (CQA) is a physical, chemical, biological, or microbiological property that must be held within a limit to assure product quality — for mAb-A, SEC monomer and HMW aggregate (size variants), CEX main peak (charge variants), host-cell protein (a process-related impurity), and protein concentration (strength). A critical process parameter (CPP) is a parameter whose variation across its range has a demonstrated effect on a CQA, established by a quality risk assessment (ICH Q9) and a design-of-experiments study, and therefore held within a normal operating range (NOR) inside a wider proven acceptable range (PAR). The dataset makes this concrete: FeedRate carries hasCriticality HIGH (established by RA-01, an ICH Q9 risk assessment), a NOR of 0.35–0.45 and a PAR of 0.30–0.50 (established by DOE-07), and affectsQuality the monomer CQA — the very chain CQ-06 and CQ-07 traverse, with the criticality and range axioms defined in Formalization. A parameter that affects only yield or cycle time, not a CQA, is a key process parameter (KPP), not a CPP, and the model keeps the distinction.

Requirements that are tests: the executable ORSD

Writing competency questions in prose is the normal practice. This book goes one step further and makes them a machine-readable, runnable artifact — because a requirement you cannot test is a requirement you cannot trust. The catalog above is mirrored byte-for-byte in examples/platform/ontology/cq-catalog.json, where each competency question names the artifact that answers it and the result it must produce. Take CQ-04 from the table above — when a lot fails, which other products share its lineage? Here is its machine-readable twin, the exact entry validate.py reads:

{
  "id": "CQ-04",
  "group": "impact",
  "question": "When a drug-product lot fails, which other drug products share its lineage (siblings via the shared cell bank)?",
  "query": "CQ-04.rq",
  "graph": "raw",
  "check": { "type": "equals", "var": "affected", "values": ["DP-001", "DP-002"] }
}

(The "graph": "raw" field selects which graph the query runs against — the asserted data as loaded, versus the inferred graph after the reasoner has added its derived facts.)

Three kinds of artifact answer the 23 questions, and the split is itself a lesson in what each tool is for:

• A SPARQL query answers 17 of them (17 .rq files in queries/, from queries/CQ-01.rq to queries/CQ-21.rq — sparse where a SHACL scenario stands in) — a SELECT whose row count, result set, matched row, or summed column is checked, or an ASK whose boolean is checked.
• A SHACL gate answers the five closed-world ones (CQ-08, CQ-10, CQ-11, CQ-17, and the disjointness-guard CQ-23) — questions of the form "is anything missing or wrong?", which assume the data on hand is complete, unlike SPARQL and OWL reasoning, which assume more facts can always be added. These are completeness, in-spec, and consistency questions a query cannot pose, because "is anything missing?" and "could this conflation slip through?" are not questions about the triples that exist. CQ-23 is the sharp case: validate.py deliberately injects a planted error (a Batch typed as a process, then as a bioreactor) and the gate passes only when the shapes graph reports non-conformance both times.
• A reasoner check answers the one purely inferential question (CQ-22) — that the OWL-RL closure actually inferred the long-range lineage and typed the equipment as a BFO material entity, rather than those facts being asserted by hand.

That is 17 + 5 + 1 = 23 — the whole catalog, each question bound to the artifact that can actually decide it.

validate.py reads the catalog, runs every entry, prints a pass/fail line per competency question, and exits non-zero if even one fails. The requirements document and the test suite are now the same file. When a later chapter adds a class or an edge, it does not get to claim success until the relevant CQ-XX still passes — which is exactly the SAMOD test-first loop, enforced by a script rather than by good intentions. The next chapter introduces the dataset those tests run against and shows the full table, green; when it appears, the three-artifact split returns as evidence you can read off each row — a SPARQL row count for CQ-01 ("11 row(s)"), a SHACL verdict for CQ-08 ("DS-001 release panel complete and in spec"), and the reasoner's word for CQ-22 ("transitive lineage + equipment-is-material inferred").

The harness runs entirely offline and on stock open-source parts — rdflib parses the three Turtle files into one in-memory graph, the rule-based owlrl engine computes the OWL 2 RL closure that CQ-22 reads, and pyshacl runs the closed-world gates — so anyone with the repo can re-derive every pass/fail line on a laptop with no network and no licensed reasoner. That choice is what makes the ORSD an executable artifact rather than a prose template, and it is the same RDFLib-and-SHACL stack the open-source book builds a plant-scale digital-thread knowledge graph on, served at scale from an Apache Jena Fuseki triplestore — this catalog is that book's two textbook competency questions (lineage and originating-batch monomer) turned into 23 and made to gate the build.

The ORSD is the ground truth a learning model is graded against

A competency-question harness and a machine-learning validation harness are, structurally, the same idea aimed at two different artifacts. The companion ML book grades a model against a pre-stated acceptance gate on a hash-pinned dataset, exiting non-zero when the evidence misses the bar; this chapter grades a graph against 23 pre-stated competency questions, exiting non-zero when one fails. That parallel is not decoration — it is why the same ORSD that disciplines the model is also the substrate an AI standing on top of it is judged against, and it sharpens three ML disciplines the retrieval-augmented-AI end-use listed in Section 3 only gestures at.

Grouped, not row-wise, evaluation. A graph of instances is not a flat table of independent rows. A campaign's hundreds of in-process measurements all descend from one cell bank through one bioreactor run, so they are correlated by derivedFrom, not independent — and a model evaluated by splitting those rows at random will see siblings of every test row already in training and report a flattering score that collapses on a genuinely new batch. The honest split holds all of one batch's instances out at once — grouped, leave-one-batch-out cross-validation — and the graph already carries the grouping key: the lineage edge CQ-04 walks is exactly the join that tells you which instances belong to the same independent unit. The structure that answers the lineage and impact questions is what defines an admissible evaluation fold, the point the models-and-validation chapter makes from the ML side.

SHACL-validated training data. The five closed-world gates above (CQ-08, CQ-10, CQ-11, CQ-17, CQ-23) were written to refuse a non-conformant release; the identical SHACL shapes refuse a non-conformant training set or a non-conformant retrieval. Before a subgraph is handed to a model — to learn from, or to ground an answer on — conformance certifies that every lot carries its derivedFrom parent, every CQA its unit-bearing value (CQ-19), every signature its signer (CQ-09), rather than a partial load the model will silently complete from training memory. A graph that fails its shapes is precisely the hollow input a fluent model narrates over without hesitation, so the release gate doubles as a data-quality gate on the learning corpus.

The validation paradox: a model versus a reasoned graph. The two harnesses also fail differently, and the difference is the whole argument for grounding. A statistical model can be confidently wrong with no internal signal — it returns a crisp number outside its training envelope as readily as inside it. The reasoned graph cannot: derivedFrom is a genuine owl:TransitiveProperty, so the lineage CQ-22 infers is entailed, not estimated, and the disjointness guards CQ-23 plants make a contradiction (a Batch typed as a process) a detectable error rather than a quiet mis-prediction. That is why the executable ORSD is the right thing to stand a model on: it certifies the facts by reasoning and constraint, where the model only ever approximates them — and a retrieval query for grounding is, byte-for-byte, the lineage competency question the harness already keeps green.

The unsolved part: a brief is a judgment, not a proof

The ORSD disciplines the model, but it cannot certify that the right questions were chosen. A competency question catalog is a claim about what matters, made by people, before the hard cases are known — and a model that answers all 23 of its questions can still be useless for the 24th that no one thought to write down. Scope is the perennial failure mode: every investigator who hits a wall wants "just one more" entity, and an ORSD that grows without discipline becomes the boundaryless model it was meant to prevent. So the ORSD is a living document under the same change control as the ontology itself: new competency questions are proposed, justified, and either admitted with their own test or refused with a reason. The executable catalog makes the refusals honest — a question not in cq-catalog.json is a question the model does not promise to answer, and says so out loud.

Why it matters

Starting from requirements is what keeps an ontology finite, testable, and trusted. Without the ORSD, "is the model done?" has no answer and "is the model correct?" has no test; with it, both reduce to running validate.py and reading 23 lines. Every later chapter in this book earns its classes and axioms by pointing at the competency question they serve — and if it cannot, the content does not belong in the model. That is the difference between an ontology that is engineered and a vocabulary that merely accreted.

In the real world

The competency-question discipline is not academic folklore; it is the spine of the methodologies industry actually adopts. NeOn's ORSD template is used across European ontology projects and taught as the standard requirements artifact [2]; SAMOD's test-first loop mirrors how agile software teams already work, which is why it transfers cleanly to engineering organizations [3]; and LOT was built explicitly for industrial ontology development and is used in standards bodies and large companies to publish reusable vocabularies [4]. What is still rare — and what this book argues for — is making the competency questions executable, so the requirements and the regression suite never drift apart.

There is also a static complement to this dynamic testing. Tools like OOPS! (the OntOlogy Pitfall Scanner) read the model itself and flag structural smells — missing disjointness declarations, properties without a domain or range, classes left unconnected — the very faults that CQ-23's disjointness guard and CQ-08/CQ-19's completeness gates catch at runtime. The scanner inspects the model at rest; validate.py exercises it against data. A mature project runs both, and this book returns to OOPS! in Formalization and Maintenance.

The functional requirements also dictate where the graph's facts come from, which is the same plant data stack the data-management book maps. The derivedFrom genealogy and equipment-vs-batch split (CQ-21) are an ISA-95 / IEC 62264 story — material lots, equipment elements, and the ISA-88 phases a batch passes through — and a unit-bearing measurement (CQ-19) is the lift the data book calls turning a bare OPC UA tag, a Level-0 process value with no context, into a typed quantity; the release record (CQ-08) is the kind of fact a B2MML batch-record message carries between Level 3 and Level 4. The graph is the data shadow — the full digital record a batch casts — reconciled into one reasoned form, and the ORSD is what fixes which shadows it must keep. Two requirements above are quietly regulatory in the same way the data book's CSV-to-CSA chapter is: the attributable signature CQ-09 checks and the controlled status set are the ontology's expression of the ALCOA+ attributes and the 21 CFR Part 11 / EU Annex 11 electronic-records controls, and because the executable harness concentrates its pass/fail gates on the facts that bear on a release decision rather than testing every triple uniformly, it is itself an instance of the risk-based CSV-to-CSA shift the quality book argues for — assurance proportional to patient risk, not paperwork spread evenly.

Key terms

• Competency question (CQ) — a query the finished ontology must be able to answer, written before modeling; the unit of requirement and, here, also the unit of test.
• ORSD (Ontology Requirements Specification Document) — the agreed brief fixing the ontology's purpose, scope, users, uses, functional requirements (the CQ catalog), non-functional requirements, and pre-glossary.
• NeOn methodology — a scenario-based ontology-engineering method; the source of the ORSD and of the reuse process Part II follows.
• SAMOD — the Simplified Agile Methodology for Ontology Development; the test-first "modelet" loop each modeling chapter runs.
• LOT (Linked Open Terms) — an industry-oriented method for requirements → implementation → publication → maintenance of reusable vocabularies.
• Executable competency question — a CQ bound in cq-catalog.json to a SPARQL query, SHACL gate, or reasoner check, run as a pass/fail test by validate.py.
• SPARQL — the query language for graph data; asks "which rows match?" — the equivalent of SQL for a knowledge graph.
• SHACL — a validation language; checks "is anything required missing or out of spec?" against the data the graph already holds (a closed-world question).
• Reasoner — a tool that derives new facts implied by the model (for example, the transitive lineage edges of derivedFrom) rather than only reading the facts asserted by hand.
• Grouped (leave-one-batch-out) cross-validation — evaluating a model by holding out all of one batch's correlated instances at once, using the graph's derivedFrom lineage as the grouping key, so the held-out score is not flattered by sibling rows leaking into training.
• SHACL-validated training data — using the release gate's SHACL shapes to certify a subgraph is complete and well-typed before a model learns from it or grounds an answer on it, so the model never silently completes a hollow input.

Where this leads

The brief is written and made runnable. The next chapter, The Running Example and the Proof Harness, introduces the single monoclonal-antibody campaign every later chapter models, the dataset files that hold it, and the harness that turns this catalog of 23 competency questions into a table of 23 passing tests — the green baseline the whole book is built to keep.