Is the Production Readiness Assessment an automated code scan?

No. Automated analysis may provide useful evidence, but the assessment combines system context, assurance claims, technical artefacts, testing, operational measurement and senior engineering analysis.

Does Lornets certify that software is production ready?

No. Lornets reports a readiness position of Ready, Conditionally Ready or Not Demonstrated Ready for a defined scope and operating context, supported by Assurance Confidence and any Critical Readiness Gates. Lornets does not certify software.

Do you apply the same standard to every application?

No. The controls, maturity and evidence expected depend on the System Context Profile: what the software does, what data it handles, who can reach it and what failure would cost.

Can a strong overall result still lead to a negative readiness conclusion?

Yes. A Critical Readiness Gate is a material technical condition that can prevent a positive Readiness Position for the defined operating context, regardless of stronger findings elsewhere.

What is Assurance Confidence?

It states how strongly the technical conclusions are supported by the evidence reviewed. It is an evidence-strength assessment rather than a statistical confidence interval or a predicted failure probability.

Is your methodology based on recognised standards?

Lornets authors its own assurance criteria and maps them against recognised software-quality, architecture, security, delivery and AI-risk sources. That is a mapping and alignment, not compliance or certification.

Is the Lornets methodology an industry standard?

No. It is Lornets' repeatable, standards-aligned production assurance methodology. Recognised standards and research inform or map to relevant criteria, but Lornets does not present its methodology as an external standard or certification scheme.

Lornets Production Assurance Methodology v1.0

Evidence before opinion.

Production readiness is not the output of a generic checklist or a single number. It is a structured, evidence-based argument about whether software can support a clearly defined operating context.

Lornets establishes what the software must withstand, defines the technical claims that need to hold, collects evidence, measures and verifies where meaningful, and then states a readiness position with the engineering decisions that follow from it. The approach is evidence-based, standards-aligned and context-sensitive. It supports senior engineering judgement rather than pretending to replace it.

Book a readiness call

How a conclusion is reached

The sequence below is applied in every engagement. Depth varies with the operating context; the order of reasoning does not.

01System ContextWhat must the software withstand?
02Assurance ClaimsWhat technical conditions need to be true?
03EvidenceWhat supports or challenges those claims?
04Measurement and VerificationWhat can be directly tested or meaningfully measured?
05Technical AssessmentWhat does the evidence establish across the relevant Production Assurance domains?
06Assurance ConfidenceHow strongly can the technical conclusion be substantiated?
07Critical Readiness GatesAre there material findings that can prevent a positive readiness conclusion?
08Readiness PositionWhat conclusion can responsibly be reached for the defined scope and operating context?
09Engineering DecisionWhat should remain and what should change?
10Verification and ReassessmentDid intervention actually improve the technical position, and does the conclusion remain valid as the system changes?

One

Production readiness is contextual.

Before detailed assessment, Lornets establishes a System Context Profile describing what the software actually needs to withstand.

The same control does not necessarily require the same maturity in every operating context. A small internal application and a system supporting sensitive financial operations should not automatically be evaluated against identical thresholds. Context determines which criteria apply, what maturity is required and what evidence is expected.

Operational criticality: What happens to customers, employees or the business if the system fails?
Data sensitivity: What information does the system collect, process, expose or control?
Exposure: Who can interact with the system and what external attack or failure surfaces exist?
Commercial scrutiny: Is the product facing fundraising, enterprise procurement, contractual commitments or another external review?
Organisational dependency: How dependent have customers or internal operations become on the system?
Scale and load profile: What usage, transaction, concurrency or data volumes must the system realistically support?
Change velocity: How frequently is the system changed and how much production risk is introduced through delivery?
AI consequence: Where AI is used, what happens when an AI component produces an incorrect, unsafe or unexpected result?

Two

Define what must be true.

Lornets does not simply ask whether a checklist item exists. Material technical conclusions are structured around an assurance claim: a condition that needs to hold for the stated operating context, and which evidence should be able to support.

Claim · Evidence · Verification · Conclusion

This structure draws on recognised assurance-case principles. Lornets does not provide a formal safety certification or a regulated assurance case.

Claim: The technical condition that must be true for the stated operating context.
Evidence: The artefacts, tests, measurements and operational records reviewed.
Verification: What was independently demonstrated rather than described.
Conclusion: Supported, partially supported or not demonstrated, with limitations stated.

Illustrative claim, not client data

Claim: Customer data cannot be accessed by another customer without appropriate authorisation.
Evidence: Authorisation implementation, access-control configuration, automated tests and targeted verification.
Finding: Supported, partially supported or not demonstrated.
Limitations: Areas where the evidence reviewed is incomplete.

Three

The Lornets Evidence Hierarchy

An engineering assertion and demonstrated operational evidence are not equivalent. Every material conclusion carries an evidence level describing how strongly it can currently be substantiated.

The five Lornets evidence levels
Level	Name	Meaning
E0	No evidence	The required behaviour or control cannot currently be substantiated.
E1	Asserted	The team reports that the behaviour or control exists, but independent evidence has not yet been reviewed.
E2	Artefact evidenced	Source code, configuration, infrastructure, documentation or another technical artefact supports the claim.
E3	Verified	The behaviour or control has been demonstrated through a repeatable test, exercise or verification process.
E4	Operationally evidenced	Production telemetry, operational records, repeated exercises or other real-world evidence demonstrates that the control or behaviour is functioning as intended.

A higher evidence level does not automatically mean greater technical maturity. Implementation maturity and evidence strength are recorded as separate properties of the same finding.

“Backups are enabled” is not treated as equivalent to “a production restoration has been successfully exercised and verified.”

The Evidence Ledger

The ledger makes each material conclusion traceable back to the evidence behind it. Client evidence remains confidential; only the structure is described publicly.

Finding ID
Assurance claim
Domain
Evidence reviewed
Evidence level
Verification performed
Technical conclusion
Limitations
External standards mapping where applicable
Decision
Priority
Verification requirement

Four

Measure where measurement is meaningful.

Lornets uses quantitative evidence where metrics genuinely describe system behaviour, and structured expert evaluation where they do not. False numerical precision is worse than an honest technical judgement.

Where no reliable delivery history or operational telemetry exists, the metric is not estimated. Missing measurement evidence is itself recorded as an assessment finding.

Reliability

Availability against defined objectives
Error rates
Incident frequency
Recovery performance
RTO
RPO
Backup restoration evidence
Dependency failure behaviour
Failed-job behaviour
Graceful degradation

Performance and scalability

p50 latency
p95 latency
p99 latency
Throughput
Concurrency
Resource saturation
Database latency
Query behaviour
Queue depth
Connection utilisation
Load-test headroom
Degradation under load

Software delivery

Change lead time
Deployment frequency
Failed deployment recovery time
Change fail percentage
Deployment rework rate

DORA currently defines these five metrics as measures of software delivery performance. They are used only where sufficient reliable delivery history exists. Where it does not, the absence of measurable evidence is recorded as an evidence limitation rather than estimated.

Methodological rigour

These are the controls applied to the work itself. Lornets does not hold industry benchmark datasets, validated predictive scoring, completed inter-assessor reliability studies or externally validated calibration, and does not claim them.

Validity: Does the measure or test actually address the technical property it claims to assess?
Reliability: Would comparable measurement under similar conditions produce reasonably consistent results?
Reproducibility: Can another competent Lornets assessor understand and reproduce how the finding was reached?
Traceability: Can each material conclusion be traced back to the evidence supporting it?

Five

Evaluate technical readiness.

Assessment is organised in two layers. Seven core Production Assurance Domains normally apply to serious production systems. Three contextual overlays are not additional equal domains and activate only where the System Context Profile makes them relevant.

What Lornets examines in each domain

Core Production Assurance Domains

Architecture and maintainability
Security and access control
Reliability and recoverability
Performance and scalability
Data and privacy engineering
Delivery and change control
Observability and operations

Contextual overlays

Enterprise Assurance
Activated where enterprise procurement, technical scrutiny, security review or customer assurance forms part of the commercial context.
AI Assurance
Activated where AI materially affects outputs, decisions, workflows or privileged actions.
Product / Operational Instrumentation
Activated where product behaviour, operational outcomes or business telemetry materially affect safe operation or decision-making.

Maturity scale

Not every criterion must reach M4. Required maturity depends on the System Context Profile. Maturity and evidence levels classify individual criteria and findings. They are not combined into an overall readiness score.

M0Absent: The capability or control is materially absent.
M1Ad hoc: Some implementation exists but it is informal, incomplete or dependent on individuals.
M2Defined: A clear implementation or process exists.
M3Controlled: The capability is applied consistently and governed, rather than depending on individual effort.
M4Operated and measured: The capability is functioning in normal operation and relevant outcomes are monitored.

Maturity: How developed and controlled the relevant technical capability is, on the M0 to M4 scale. It is recorded per criterion.
Evidence Level: How strongly the relevant claim or capability can be substantiated, on the E0 to E4 scale. It is recorded per finding.
Assurance Confidence: How strongly the overall assessment conclusion is supported by the available evidence. Maturity and evidence are never multiplied into a composite readiness score.

Six

Assess confidence separately.

Implementation maturity and evidence strength are not multiplied into a single opaque number. They are reported separately, because they answer different questions.

A system may appear technically strong but hold weak Assurance Confidence because important claims cannot be demonstrated. Another may carry known weaknesses yet hold high Assurance Confidence because its behaviour, limitations and controls are well understood and directly evidenced.

Assurance Confidence is an evidence-strength assessment. It is not a statistical confidence interval, a probability of failure or a predicted incident rate.

Technical Readiness

How capable and appropriate the system is for its stated operating context, assessed across the applicable Lornets criteria.

Assurance Confidence

How strongly that conclusion can be supported by the evidence available. It is an evidence-strength assessment, not a statistical confidence measure.

Seven

Some findings can prevent a positive readiness conclusion.

A Critical Readiness Gate is a material technical condition that may prevent a positive Readiness Position for the defined operating context, regardless of stronger findings elsewhere.

The examples below are indicative, not an exhaustive universal list. Criticality depends on the operating context.

Material broken access control
Inadequate tenant isolation
Meaningful exposure of secrets or credentials
Inability to recover business-critical data
Critical known vulnerabilities on exposed surfaces
Absence of credible recovery capability for an operationally critical system
Severe uncontrolled privileged operations
Material AI actions operating outside required permission or validation boundaries

Clear: No critical control failure identified for the stated operating context.
Conditional: A critical control is only partially substantiated, or is acceptable subject to defined remediation.
Blocked: A finding creates unacceptable risk for the stated operating context and is not offset by stronger findings elsewhere.

Eight

Reach a readiness position.

The final Lornets conclusion is a Readiness Position for a defined scope and operating context.

Lornets does not publish a composite numerical readiness score. Maturity and evidence levels classify individual criteria and findings. The conclusion is a Readiness Position for the defined scope and operating context, informed by Critical Readiness Gates, Assurance Confidence and the System Context Profile.

Ready: The evidence supports operation in the stated context without identified material blockers.
Conditionally Ready: The system can reasonably support the stated context subject to clearly identified remediation, controls or operating conditions.
Not Demonstrated Ready: Available evidence or material technical findings do not currently support a positive readiness conclusion for the stated operating context.

What the position depends on

Every conclusion is bounded. Lornets records the limits of the work alongside the position itself, so the reader can see exactly what the conclusion covers.

Conclusions apply to the defined scope, operating context, evidence and assumptions. Lornets does not state that a system is production ready in perpetuity.

Scope limitations: What was outside the assessment?
Evidence limitations: What could not be demonstrated with the evidence available?
Environmental and testing limitations: What could not safely or practically be tested?
Assumptions: What conditions does the conclusion depend on?

Based on the operating context, scope, evidence and assumptions defined in this assessment, Lornets considers the system Ready, Conditionally Ready or Not Demonstrated Ready for the stated use. The statement is always tied to that scope, evidence, assumptions and operating context. It is not a certification and not a guarantee of future system behaviour.

Nine

Decide what changes.

Every material finding resolves to a single engineering decision with a stated priority: immediate, near-term, planned or monitor.

The burden of evidence increases with the cost and disruption of the recommendation. A rewrite or migration requires materially stronger justification than a targeted refactor.

Keep: The existing implementation remains appropriate for the stated operating context.
Refactor: The existing foundation remains viable but requires improvement.
Replace: The component or approach should be replaced where the evidence justifies it.

Two decision models, two levels

The two models operate at different levels and are not contradictory. A system can remain largely in place while individual components are refactored or replaced.

Engineering Disposition: Finding, component or technical control; Keep, Refactor or Replace. Applied to a specific technical condition identified during assessment.
Platform Transition Strategy: System or platform; Stay, Refactor, Hybrid or Migrate. Applied to the operating foundation as a whole.

Platform Transition Strategy

Stay: Remain on the existing foundation.
Refactor: Keep the foundation and change the constrained parts within it.
Hybrid: Preserve significant working parts while selectively externalising or replacing constrained components.
Migrate: Move the material operating foundation where the evidence justifies transition.

Illustrative combination

Platform strategy: Hybrid
User interface: Keep
Authentication: Refactor
Background processing: Replace

Every material finding follows the same structure

Observation: What was identified.
Assurance claim: The technical condition that needs to be true in this context.
Evidence: What supports or challenges that claim.
Evidence strength: Recorded on the E0 to E4 evidence hierarchy.
Risk: What can technically go wrong.
Business consequence: Why it matters in the current operating context.
External reference: Relevant standard, research or recognised framework where useful.
Decision: Keep, Refactor or Replace.
Priority: Immediate, near-term, planned or monitor.
Verification criterion: What evidence will demonstrate that remediation is complete.

Illustrative methodology example, not client data

Observation: Production database backups are configured.
Evidence: Backup configuration reviewed.
Evidence level: E2 · Artefact evidenced.
Gap: No successful restoration exercise could be demonstrated.
Risk: Backup availability does not establish recoverability.
Decision: Refactor.
Verification: Execute and document a successful restoration exercise against the agreed recovery objectives.

One methodology, applied through service lenses.

The core Production Assurance Methodology remains universal. Individual services apply additional lenses to the same technical position rather than substituting a different method.

Fundraise Technical Readiness: What does the technical position mean under investor scrutiny?; Investment Materiality / Technical Claims Register / Evidence Readiness / Technical Diligence Challenge
Enterprise Readiness: What does the technical position mean under customer and procurement scrutiny?; Customer Requirement Mapping / Enterprise Claims and Evidence Matrix / Procurement Blockers / Technical Commitment Review
Platform Transition & Migration: Is the current technical foundation still appropriate?; Production Boundary Map / Stay, Refactor, Hybrid or Migrate / Decision criteria and transition economics / Verification where transition is justified
Managed Production Engineering: Has the previously established production position materially changed?; Production Assurance Baseline / Assurance Drift / Stewardship remit / Recurring production position

Ten

Verify remediation.

Remediation is not complete when code changes. Material remediation should finish with evidence demonstrating that the identified risk has actually been reduced.

Finding → Target condition → Engineering intervention → Verification → Updated technical position

Improvement figures are reported from actual measurements taken before and after the work. Lornets does not publish generic improvement percentages.

Successful restoration exercise
Repeatable authorisation tests
Measured latency improvement
Load-test evidence
Reduced error rates
Controlled deployment rollback
Verified observability coverage
AI evaluation results

Engineering is not considered complete merely because code changed. The evidence supporting the relevant finding must change.

The burden of evidence increases with the cost and disruption of the recommendation.

Production Hardening & Scale

Standards and research foundations

Lornets authors its own assurance criteria. It does not invent a private definition of good engineering, and it does not reproduce external standard text. Applicable criteria are mapped against, informed by and assessed with reference to recognised sources, always using the current applicable version.

This is alignment and mapping, not compliance or certification. Lornets is not a certification body and does not claim ownership of any external framework.

01ISO/IEC 25010 (ISO/IEC, 2023)Recognised software and product quality model foundation.
02ISO/IEC 25019 (ISO/IEC, 2023)Quality in the system's context of use.
03ISO/IEC 25040 (ISO/IEC, 2024)Quality-evaluation framework reference.
04ISO/IEC/IEEE 42010 (ISO/IEC/IEEE, 2022)Architecture description, viewpoints, system boundaries and architecture evidence.
05OWASP Application Security Verification Standard (OWASP, current)Basis for testing application technical security controls and secure-development requirements.
06NIST SP 800-218, Secure Software Development Framework (NIST, 2022)Secure-development practices.
07NIST SP 800-218A (NIST, 2024)Secure-development practices extended for generative AI and dual-use foundation models.
08NIST Cybersecurity Framework 2.0 (NIST, 2024)Broader cybersecurity risk-management reference.
09NIST AI Risk Management Framework 1.0 (NIST, 2023)AI risk-management reference.
10NIST Generative AI Profile (NIST, 2024)Companion profile to the AI RMF for generative AI risks.
11ISO/IEC 42001 (ISO/IEC, 2023)Requirements and guidance for an AI management system, where management-system considerations are relevant.
12DORA software delivery performance metrics (DORA research programme, current)Five current software delivery performance metrics, used where sufficient delivery evidence exists.
13SLSA v1.2 (OpenSSF, current)Supply-chain levels, tracks and build provenance concepts, referenced selectively.
14Empirical research on AI-assisted software quality and security (Peer-reviewed software-engineering research, recent)Large-scale comparisons of human and AI-generated code and empirical studies of security weaknesses in LLM-generated programs.

AI assurance

Activated where AI materially affects outputs, decisions, workflows or privileged actions. Lornets does not hold or claim ISO/IEC 42001 certification or certification authority.

Task-specific evaluation
Model and prompt versioning
Reproducibility
Hallucination and failure behaviour
Output validation
Prompt injection
Sensitive-data exposure
Model and provider dependency
Human review
Autonomous or agentic permissions
Privileged tool access
Monitoring
Cost controls
Fallback behaviour
Evaluation coverage

AI-assisted development can materially accelerate software creation. Functional success, however, is not sufficient evidence of production quality. Recent empirical software-engineering research has identified distinct defect and security profiles in AI-generated code, reinforcing the need for independent verification rather than assumptions based on how the software was produced.

AI-assisted development is useful. Important software still requires evidence.

The Production Assurance Dossier

The Production Assurance Dossier is the assessment record. Depth depends on the system and the engagement, and not every assessment produces every appendix.

01Executive Readiness PositionThe conclusion for the defined scope and operating context, with Assurance Confidence stated alongside it.
02Scope and System ContextThe System Context Profile, the system and architecture view, and the boundaries of the work.
03Material Findings and Critical Readiness GatesPrioritised findings with technical risk, business consequence and gate state.
04Evidence Ledger and Verification RecordEvidence reviewed, evidence levels, measurements, verification performed and stated limitations.
05Engineering Decisions and PrioritiesKeep, Refactor or Replace for each material finding, with priority and verification criteria.
06Relevant Technical AppendicesSupporting technical detail and external standards mapping where applicable.

Methodology governance

Version: v1.0
Published: 2026
Last revised: August 2026
Owner: Lornets

The Production Assurance Methodology is versioned and maintained by Lornets. Material changes to criteria, evidence guidance, gate logic, terminology or decision guidance are recorded through versioned revisions.

The methodology is structured to support multiple Lornets assessors over time through defined assessment criteria, evidence requirements, severity guidance, gate rules, decision guidance, verification requirements and assessor notes. The objective is that two competent assessors reviewing the same evidence reach broadly comparable conclusions.

Assessment and interpretation guidance is maintained with the methodology so that criteria, evidence requirements and decision guidance stay consistent between engagements.

Changelog

v1.0 · 2026: First public release. Seven core Production Assurance Domains and three contextual overlays separated, assurance claims and the Evidence Ledger introduced, technical readiness and Assurance Confidence reported separately, and the Readiness Position established as the final conclusion in place of any composite numerical score.

Common questions

Is the Production Readiness Assessment an automated code scan?: No. Automated analysis may provide useful evidence, but the assessment combines system context, assurance claims, technical artefacts, testing, operational measurement and senior engineering analysis.
Does Lornets certify that software is production ready?: No. Lornets reports a readiness position of Ready, Conditionally Ready or Not Demonstrated Ready for a defined scope and operating context, supported by Assurance Confidence and any Critical Readiness Gates. Lornets does not certify software.
Do you apply the same standard to every application?: No. The controls, maturity and evidence expected depend on the System Context Profile: what the software does, what data it handles, who can reach it and what failure would cost.
Can a strong overall result still lead to a negative readiness conclusion?: Yes. A Critical Readiness Gate is a material technical condition that can prevent a positive Readiness Position for the defined operating context, regardless of stronger findings elsewhere.
What is Assurance Confidence?: It states how strongly the technical conclusions are supported by the evidence reviewed. It is an evidence-strength assessment rather than a statistical confidence interval or a predicted failure probability.
Is your methodology based on recognised standards?: Lornets authors its own assurance criteria and maps them against recognised software-quality, architecture, security, delivery and AI-risk sources. That is a mapping and alignment, not compliance or certification.
Is the Lornets methodology an industry standard?: No. It is Lornets' repeatable, standards-aligned production assurance methodology. Recognised standards and research inform or map to relevant criteria, but Lornets does not present its methodology as an external standard or certification scheme.

Assurance is not necessarily a one-time event

Where software remains commercially or operationally important, material system changes may justify ongoing evidence review and periodic reassessment. The divergence between the position previously established and the real system as it changes is called Assurance Drift.

Observe → Review → Prioritise → Intervene → Verify → Update

This recurring loop is applied through Managed Production Engineering, which maintains the Production Assurance Baseline and updates the current position using new evidence.

Managed Production Engineering

Where the methodology is applied

Production Readiness Assessment Production Assurance Framework Fundraise Technical Readiness Enterprise Readiness

Fundraise-specific application

Fundraise Technical Readiness applies the core methodology unchanged and adds four elements: an Investment Materiality Lens, a Technical Claims Register, Evidence Readiness derived from Assurance Confidence, and a Technical Diligence Challenge Session with management before completion.

Enterprise-specific application

Enterprise Readiness applies the same methodology and adds Customer Requirement Mapping, an Enterprise Claims and Evidence Matrix, Procurement Blockers held separate from Critical Readiness Gates, and a Technical Commitment Review of the availability, recovery and security commitments management is considering.

Book a readiness call