The document a client receives before we write any code

Why it exists

A blueprint is how both sides find out whether we understood the work. It is cheaper to be wrong in a document than in a system, and the client can act on it even if they never build anything with us.

It is also the only honest way to price the work. Nobody can quote a process they have not watched running.

What is in it

The process as it actually runs, step by step, including the exceptions we found and who handles them today. The systems it touches, what is read from each, and what is written back. The controls: who approves what, what is logged, and what the system is never allowed to do.

Then the part most documents leave out: what we are not going to build, and why. A process about to be replaced, or a step whose rules genuinely need a person, belongs in that section.

How it is produced

It is produced by sitting with the people who do the job, for as long as it takes to see the cases that do not fit.

It is written in the client's own vocabulary. If an underwriter or an estimator cannot correct it, it is not finished.

And it is specific enough to be argued with. A blueprint nobody objects to usually means nobody has read it closely.

What happens after it

Reviewed by the people who will live with it

The client's engineers review every integration in it, and their security team reads the controls section before anything is built. Objections at that stage are cheap.

Then it becomes the build

What was written guides the build, and where reality forces a change the blueprint needs to change with it. It remains the document that explains what the system does.