Start from where your project stands

18 months after a design is delivered, someone asks a plain question. What did that figure rest on? Who decided to leave the second pump out? Which drawing did the estimate use? Software teams can answer questions like these about their own work, because they keep a few habits: a written specification, decisions recorded with a date and a reason, pinned inputs, reviews before release, and releases that are never changed afterwards.

We have started running our assignments that way, beginning with the two in progress now. We call it Project as code.

One private record per project

Each assignment has one private project record of its own. The customer never sees it; it is where our engineers and our software work. It holds five things, each with one rule:

What it holds	The rule
The agreed scope	What we deliver, by when, and what you bring. Everything refers to it.
What you handed over	Registered as received. A new revision is a new entry; nothing is edited.
Decisions	A date, a name and a reason. A wrong one is replaced by a new one.
The work	Every calculation names the documents and the tool version it used.
What you received	Never changed. A correction is a new revision that names the old one.

Your stage comes first

Process-industry owners invest in stages, usually called front-end loading: a business case, then concept selection, then project definition, each ending in the owner's decision. After the investment decision the project is in execution. Some parties call execution "FEL 4"; we read those documents as execution plans and quote their titles as they are.

From now on, before work starts, we record which stage your project is in. Then we check what you handed over against what that stage normally holds. For that we use the deliverable maturity in AACE International's cost estimate classification for the process industries (Recommended Practice 18R-97). It ties each estimate class to how far key deliverables, such as process flow diagrams and P&IDs, have been developed. We tell you early what is there, what is partial and what is missing, so the gaps are known before the date, not on it.

Your gates stay yours

Every party on a project runs its own stage-gate process. An energy company has its decision gates, a building owner the Finnish building phases, and the authorities the environmental impact assessment (Act 252/2017) and the environmental permit (Act 527/2014). A manufacturer has its conformity assessment under the Pressure Equipment Directive 2014/68/EU or the Machinery Regulation (EU) 2023/1230. We keep a library of these, built from the laws, standards and the companies' own published project documents, and record with each project which ones apply and where each stands.

The gate decisions are yours. Our reviews prepare your next decision. They never stand in for it.

The same context for every engineer and every agent

Our engineers work with AI agents. An agent that starts work on your project is told the same things a new engineer would be told: the stage, the next decision and who takes it, which frameworks apply, and what is still missing. That briefing is one file at the root of the project record, written from the project's settings by a script on every change, and a check on every update refuses it when it is out of date. Knowledge an agent adds, such as how a customer numbers its documents, stays a proposal until a named person accepts it.

Where it stops

• The stage check reads which deliverables exist and how far each is developed. It is not an engineering review of their content.
• Our framework library says, for each source, whether we read it in full or only in a summary. Some companies' gate models are published only in part, and we mark them that way.
• The project record is ours. You see the work through your project space, where released revisions and your answers to them are kept.

If you have a project heading for an investment decision and want to know what your material supports before the work starts, bring it to a call.