Practice
Production Assurance & Engineering
For software that already exists and has become commercially or operationally important.
What this practice is
This practice establishes what an organisation can actually rely on its software to do, and then engineers what the evidence justifies. It covers independent assessment, diligence and enterprise scrutiny, remediation and platform change, and ongoing production engineering once the position has to be held over time.
Assessment can be commissioned on its own. Where another party is better placed to carry out the work, or where independence would be compromised by doing it ourselves, we say so in the conclusion.
When it becomes relevant
Usually nothing has changed in the software. What changed is what the business is now asking it to withstand.
- The product now carries real customers, revenue or operational dependency.
- An enterprise buyer is scrutinising security, resilience, data handling or controls.
- Fundraising or technical diligence is approaching and claims will be challenged.
- A rewrite, migration or platform change is being proposed.
- Incidents, performance problems or maintenance friction are becoming material.
Three questions bring people here.
Most engagements start with one of these, not with a service name.
Can we depend on it?
Establish the real technical position before anyone commits to it, whether the pressure comes from growth, an investor or a customer.
Make it hold
Turn material findings into defined engineering work, or resolve whether a larger platform change is genuinely justified.
Keep it holding
Hold the technical position as the system, the team and the commercial demands keep changing.
How we work, and what you receive
Every conclusion is tied to what was observed, how strongly it was evidenced and what follows commercially if it holds or fails. Engineering work is scoped from those findings, with acceptance criteria agreed before it starts and verification at the end.
Findings are written as technical conclusions with their basis attached, so the document can be handed to an investor, a customer or an engineering team without translation.
Domain 03Reliability & RecoverabilityPayments path
The service survives instance loss, but regional recovery is documented rather than demonstrated.
Evidence considered
Failover has been exercised at instance level, with recovery times captured each time.
The stated fifteen minute recovery objective is a commercial commitment. Nothing in the evidence supports it under a regional event.
Current failover runbook, prior recovery exercise records, incident history and architecture review.
Evidence strength
E2
Observed under controlled test conditions, not under a production event.
Assurance confidence
Moderate
Sufficient evidence to conclude on instance recovery, not on regional recovery.
Critical gate
Conditional
A regional recovery must be rehearsed and instrumented before the fifteen minute objective is put in front of an enterprise buyer.
Engineering disposition
Refactor
The recovery design is sound. The gap is in what has been demonstrated, not in the architecture.
Illustrative example. Not client data.
Who this is for
Lornets is most useful when the software already matters and the organisation needs a defensible technical decision about what happens next.
Less likely to be a fit
You are still validating whether anybody wants the initial product.
You mainly need developers to build a first MVP.
You already know exactly what engineering work is required and only need additional coding capacity.
You are looking specifically for a penetration test, certification audit or SOC 2 / ISO certification body.
The software is non-critical and there is no meaningful commercial or operational consequence if it fails.
Start here
Unless diligence or an enterprise review is already underway, the Production Readiness Assessment is the default entry point. It establishes the position first, so any engineering that follows is argued rather than assumed.