{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"domain-knowledge-as-the-moat","title":"The facts that exist in no corpus","url":"https://addaly.com/learn/how-software-changed/domain-knowledge-as-the-moat","position":81,"of":87,"minutes":9,"answer":"The rules that decide whether software is correct live in regulations, in practitioners' heads and in the behaviour of the system being replaced.","keyIdea":"The rules that decide whether software is correct live in regulations, in practitioners' heads and in the behaviour of the system being replaced, so acquiring them deliberately is what converts fast generation from plausible output into correct output."},"body":{"format":"markdown","text":"## Why this is the durable advantage\n\nModule four covered writing a specification. This lesson is about the prior step nobody teaches: **acquiring the knowledge that goes in one.**\n\nA model has read enormous quantities of code and prose. What it has not read is the conversation in which your finance director explained that a refund issued after the month-end close has to be dated to the new period, or the email chain establishing that a shipment can be split but a return cannot.\n\nThose facts are not rare or advanced. They are ordinary, and they are the difference between software that works and software that looks like it works. They exist in three places only: in regulations, in the heads of the people who do the job, and in the behaviour of the system you are replacing.\n\n## What a domain fact looks like\n\nConcrete, because abstract versions of this are useless.\n\n- **Clinical results can be amended after being reported.** A result is not immutable, a report referencing it must show which version it used, and the amendment has to be visible to whoever acted on the original. A schema with a single `result` column has already lost.\n- **A payment can settle days after it is authorised, and can fail then.** \"Paid\" is not one state. Systems that model it as a boolean generate a reconciliation problem that will be somebody's full-time job.\n- **VAT reverse charge** moves the obligation to the buyer for some cross-border business supplies. An invoice total that ignores this is wrong in a way no test will catch, because the test was written from the same misunderstanding.\n- **Names.** People have one name, or four, or a name that changes, or characters outside your collation. A required `first_name` and `last_name` is a decision about who is allowed to be a customer.\n- **Addresses.** Postcodes are not universally present, not universally unique, and not universally stable. Validation copied from a US-shaped example rejects real addresses in much of the world.\n\nThe common property: each is a rule somebody decided, for reasons outside software, that cannot be derived from first principles.\n\n## How to actually acquire it\n\n**Watch somebody do the job.** Two hours next to the person using the system you are replacing beats two weeks of requirements documents. Watch what they do in the spreadsheet they keep alongside your software, because that spreadsheet is a list of everything your software gets wrong.\n\n**Read the primary source.** Regulations are public, and some of the standards that matter are free: ITU-T E.164 for phone numbers, and the ISO 4217 currency-code list, which its maintenance agency SIX publishes at no charge. Others are sold. ISO 8601 for dates costs CHF 181 from ISO, but RFC 3339, a free profile of ISO 8601, covers most software needs. They are dull and specific, which is exactly why they contain the answers.\n\n**Learn the vocabulary precisely.** In every domain there are words that look like ordinary English and are not. \"Settlement\", \"reconciliation\", \"accrual\", \"triage\", \"consignment\", \"break\". Using one loosely in a meeting marks you as an outsider; using it precisely gets you told the real rules.\n\n**Collect the exceptions.** Ask: when does the normal process not apply? Every business has a handful of cases that generate most of the complexity, and practitioners will list them immediately if asked directly, and will never volunteer them.\n\n**Write down what you learn where the code is.** A `docs/domain.md` explaining what a settlement window is, in the repository, next to the code that implements it. This is the artefact that makes everything else you generate better, because it is the context that was missing.\n\n## The interaction with generated code\n\nThis is where the two halves of the course meet.\n\nA model given your domain knowledge in the prompt performs enormously better than one working from generic patterns. Not because it learned anything, but because the ambiguities that would otherwise be resolved by \"what is most common\" get resolved by your actual rules.\n\nSo domain knowledge is now leveraged rather than just useful. The person who knows the business and can write it down clearly produces correct software much faster than they used to. The person who knows neither produces plausible software faster than they used to, which is worse than before.\n\n## Honest about the limits\n\nDomain knowledge is not a permanent moat. It is written down eventually, competitors hire your people, and some domains are well covered in public material: a standard e-commerce checkout is not a secret.\n\nIt is also slow to acquire: a year in a domain before you are useful is normal, which makes it bad advice for someone who needs a job this month. And it ties you to a sector, which is a real cost if that sector contracts.\n\nWhat can be said cleanly is narrower: of the things you might spend a year learning, the ones grounded in a specific industry's rules depreciate slower than the ones grounded in a specific tool's syntax."},"check":{"question":"Why does writing a domain glossary into the repository improve generated code, given the model learns nothing from it?","options":[{"text":"It gives reviewers a shared reference, so mistakes are caught more consistently during review.","correct":false,"tempting":"A genuine benefit, but it describes an effect on humans rather than on what gets generated."},{"text":"Ambiguities that would default to the most common pattern get resolved by your actual rules instead.","correct":true},{"text":"Domain terms in the repository will be included in future training data, improving the model over time.","correct":false,"tempting":"Assumes a training feedback loop that does not operate on a private repository."},{"text":"It reduces the number of tokens needed per request, leaving more of the context window for code.","correct":false,"tempting":"A glossary adds context rather than saving it; the benefit is what the added context determines."}]},"prev":{"slug":"one-way-doors","title":"Decisions that do not swing back","url":"https://addaly.com/learn/how-software-changed/one-way-doors"},"next":{"slug":"the-ten-year-cost","title":"Writing cost, and the cost that follows it","url":"https://addaly.com/learn/how-software-changed/the-ten-year-cost"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The facts that exist in no corpus', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/domain-knowledge-as-the-moat (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The facts that exist in no corpus","courseTitle":"How Software Development Changed","module":{"index":9,"slug":"what-did-not-change","title":"What did not change, and what to do now"},"answer":null,"keyIdea":"The rules that decide whether software is correct live in regulations, in practitioners’ heads and in the behaviour of the system being replaced, so acquiring them deliberately is what converts fast generation from plausible output into correct output.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"why-this-is-the-durable-advantage","runs":[{"text":"Why this is the durable advantage"}]},{"t":"p","runs":[{"text":"Module four covered writing a specification. This lesson is about the prior step nobody teaches: "},{"text":"acquiring the knowledge that goes in one.","b":true}]},{"t":"p","runs":[{"text":"A model has read enormous quantities of code and prose. What it has not read is the conversation in which your finance director explained that a refund issued after the month-end close has to be dated to the new period, or the email chain establishing that a shipment can be split but a return cannot."}]},{"t":"p","runs":[{"text":"Those facts are not rare or advanced. They are ordinary, and they are the difference between software that works and software that looks like it works. They exist in three places only: in regulations, in the heads of the people who do the job, and in the behaviour of the system you are replacing."}]},{"t":"h2","id":"what-a-domain-fact-looks-like","runs":[{"text":"What a domain fact looks like"}]},{"t":"p","runs":[{"text":"Concrete, because abstract versions of this are useless."}]},{"t":"ul","items":[[{"text":"Clinical results can be amended after being reported.","b":true},{"text":" A result is not immutable, a report referencing it must show which version it used, and the amendment has to be visible to whoever acted on the original. A schema with a single "},{"text":"result","code":true},{"text":" column has already lost."}],[{"text":"A payment can settle days after it is authorised, and can fail then.","b":true},{"text":" “Paid” is not one state. Systems that model it as a boolean generate a reconciliation problem that will be somebody’s full-time job."}],[{"text":"VAT reverse charge","b":true},{"text":" moves the obligation to the buyer for some cross-border business supplies. An invoice total that ignores this is wrong in a way no test will catch, because the test was written from the same misunderstanding."}],[{"text":"Names.","b":true},{"text":" People have one name, or four, or a name that changes, or characters outside your collation. A required "},{"text":"first_name","code":true},{"text":" and "},{"text":"last_name","code":true},{"text":" is a decision about who is allowed to be a customer."}],[{"text":"Addresses.","b":true},{"text":" Postcodes are not universally present, not universally unique, and not universally stable. Validation copied from a US-shaped example rejects real addresses in much of the world."}]]},{"t":"p","runs":[{"text":"The common property: each is a rule somebody decided, for reasons outside software, that cannot be derived from first principles."}]},{"t":"h2","id":"how-to-actually-acquire-it","runs":[{"text":"How to actually acquire it"}]},{"t":"p","runs":[{"text":"Watch somebody do the job.","b":true},{"text":" Two hours next to the person using the system you are replacing beats two weeks of requirements documents. Watch what they do in the spreadsheet they keep alongside your software, because that spreadsheet is a list of everything your software gets wrong."}]},{"t":"p","runs":[{"text":"Read the primary source.","b":true},{"text":" Regulations are public, and some of the standards that matter are free: ITU-T E.164 for phone numbers, and the ISO 4217 currency-code list, which its maintenance agency SIX publishes at no charge. Others are sold. ISO 8601 for dates costs CHF 181 from ISO, but RFC 3339, a free profile of ISO 8601, covers most software needs. They are dull and specific, which is exactly why they contain the answers."}]},{"t":"p","runs":[{"text":"Learn the vocabulary precisely.","b":true},{"text":" In every domain there are words that look like ordinary English and are not. “Settlement”, “reconciliation”, “accrual”, “triage”, “consignment”, “break”. Using one loosely in a meeting marks you as an outsider; using it precisely gets you told the real rules."}]},{"t":"p","runs":[{"text":"Collect the exceptions.","b":true},{"text":" Ask: when does the normal process not apply? Every business has a handful of cases that generate most of the complexity, and practitioners will list them immediately if asked directly, and will never volunteer them."}]},{"t":"p","runs":[{"text":"Write down what you learn where the code is.","b":true},{"text":" A "},{"text":"docs/domain.md","code":true},{"text":" explaining what a settlement window is, in the repository, next to the code that implements it. This is the artefact that makes everything else you generate better, because it is the context that was missing."}]},{"t":"h2","id":"the-interaction-with-generated-code","runs":[{"text":"The interaction with generated code"}]},{"t":"p","runs":[{"text":"This is where the two halves of the course meet."}]},{"t":"p","runs":[{"text":"A model given your domain knowledge in the prompt performs enormously better than one working from generic patterns. Not because it learned anything, but because the ambiguities that would otherwise be resolved by “what is most common” get resolved by your actual rules."}]},{"t":"p","runs":[{"text":"So domain knowledge is now leveraged rather than just useful. The person who knows the business and can write it down clearly produces correct software much faster than they used to. The person who knows neither produces plausible software faster than they used to, which is worse than before."}]},{"t":"h2","id":"honest-about-the-limits","runs":[{"text":"Honest about the limits"}]},{"t":"p","runs":[{"text":"Domain knowledge is not a permanent moat. It is written down eventually, competitors hire your people, and some domains are well covered in public material: a standard e-commerce checkout is not a secret."}]},{"t":"p","runs":[{"text":"It is also slow to acquire: a year in a domain before you are useful is normal, which makes it bad advice for someone who needs a job this month. And it ties you to a sector, which is a real cost if that sector contracts."}]},{"t":"p","runs":[{"text":"What can be said cleanly is narrower: of the things you might spend a year learning, the ones grounded in a specific industry’s rules depreciate slower than the ones grounded in a specific tool’s syntax."}]}],"check":{"question":[{"text":"Why does writing a domain glossary into the repository improve generated code, given the model learns nothing from it?"}],"options":[{"text":[{"text":"It gives reviewers a shared reference, so mistakes are caught more consistently during review."}],"correct":false,"tempting":[{"text":"A genuine benefit, but it describes an effect on humans rather than on what gets generated."}]},{"text":[{"text":"Ambiguities that would default to the most common pattern get resolved by your actual rules instead."}],"correct":true,"tempting":null},{"text":[{"text":"Domain terms in the repository will be included in future training data, improving the model over time."}],"correct":false,"tempting":[{"text":"Assumes a training feedback loop that does not operate on a private repository."}]},{"text":[{"text":"It reduces the number of tokens needed per request, leaving more of the context window for code."}],"correct":false,"tempting":[{"text":"A glossary adds context rather than saving it; the benefit is what the added context determines."}]}],"order":[3,0,1,2],"why":null},"prev":{"slug":"one-way-doors","title":"Decisions that do not swing back","minutes":9},"next":{"slug":"the-ten-year-cost","title":"Writing cost, and the cost that follows it","minutes":9}}}