The facts that exist in no corpus

Why this is the durable advantage

Module four covered writing a specification. This lesson is about the prior step nobody teaches: acquiring the knowledge that goes in one.

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.

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.

What a domain fact looks like

Concrete, because abstract versions of this are useless.

• 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.
• 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.
• 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.
• 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.
• 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.

The common property: each is a rule somebody decided, for reasons outside software, that cannot be derived from first principles.

How to actually acquire it

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.

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.

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.

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.

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.

The interaction with generated code

This is where the two halves of the course meet.

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.

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.

Honest about the limits

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.

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.

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.