One framework. Different commercial moments.

01

Core domain

Architecture & Maintainability

What we are trying to establish

Architecture determines the cost of every future change. Decisions that were reasonable at prototype stage constrain what can safely be changed once the software carries commercial or operational responsibility.

What we examine

System boundaries, service and module structure, coupling, state management, background processing, third-party dependencies and how the current design constrains the next twelve months of change.

Typical assurance claims

• The system can absorb the next twelve months of change without redesign of a critical path.
• A failure in one component does not compromise unrelated business functions.

Questions we ask

• Which parts of the system cannot be changed without touching everything else?
• Where does business logic actually live?
• Which third-party services would halt the product if they changed terms or availability?
• What would need to change to support ten times the current usage?

02

Core domain

Security & Access Control

What we are trying to establish

Security findings turn a technical issue into a commercial one. They surface during diligence, procurement and customer review, and they carry regulatory and reputational consequences.

What we examine

Authentication, authorisation and access control, tenant isolation, secret management, input validation, dependency vulnerabilities, exposed endpoints, storage rules and administrative access paths.

Typical assurance claims

• Customer data cannot be accessed by another customer without appropriate authorisation.
• Authorisation is enforced server-side on every protected operation.
• Production secrets are not recoverable from source control or client code.

Questions we ask

• Can one customer reach another customer's data through any code path?
• Where is authorisation enforced, and is it enforced on the server for every route?
• Which secrets have ever been committed or shared outside a secret manager?
• Who holds production access, and how is that access removed?

03

Core domain

Reliability & Recoverability

What we are trying to establish

Once a business depends operationally on software, the cost of an outage stops being technical. Real usage tests failure, recovery and data restoration whether or not they have been exercised deliberately.

What we examine

Failure modes, retry and idempotency behaviour, dependency timeouts, background job durability, backup coverage, restore testing, recovery objectives and incident response practice.

Typical assurance claims

• Business-critical data can be restored within the agreed recovery objectives.
• The system degrades in a controlled way when a critical dependency fails.

Questions we ask

• What happens if a critical dependency is unavailable?
• Can failed operations be retried safely?
• Has backup restoration actually been tested?
• What is the acceptable recovery time?
• What is the acceptable amount of data loss?

04

Core domain

Performance & Scalability

What we are trying to establish

Infrastructure and architecture programmes are sometimes committed before the actual constraint has been measured. Identifying the real constraint changes both the scope and the cost of the work required.

What we examine

Query patterns and indexing, N+1 behaviour, hot paths, payload sizes, caching, connection limits, queue depth, rate limiting and the actual measured bottleneck rather than the assumed one.

Typical assurance claims

• The system sustains the expected workload within agreed latency and error thresholds.
• The actual constraint under load has been measured rather than assumed.

Questions we ask

• What is the measured bottleneck under realistic load?
• Which queries dominate database time?
• What breaks first as concurrency rises: the database, the queue or the runtime?
• Which costs grow linearly with users, and which grow faster?

05

Core domain

Data & Privacy Engineering

What we are trying to establish

A weak data model or an unclear retention position becomes considerably more expensive to correct after the dataset grows and after customers begin asking where their data goes.

What we examine

Data model integrity, migrations, retention, personal data handling, residency, encryption at rest and in transit, deletion paths, logging of sensitive values and data shared with third parties including model providers.

Typical assurance claims

• Personal data is stored, shared and deleted as committed to customers.
• Sensitive values are not exposed through logs, exports or third-party integrations.

Questions we ask

• What personal data is held, and why?
• Can a customer's data be exported and deleted completely?
• Which third parties, including model providers, receive customer data?
• Are migrations reversible, and are they tested before production?

06

Core domain

Delivery & Change Control

What we are trying to establish

Delivery practice determines how quickly a team can fix a serious problem. Investors and enterprise customers read it as a proxy for engineering maturity.

What we examine

Environment separation, branching and review practice, automated testing coverage on critical paths, build and deployment pipeline, rollback capability, configuration management and release frequency.

Typical assurance claims

• A harmful change can be reverted quickly and safely.
• No unreviewed change can reach production.

Questions we ask

• Can a change be reverted in minutes?
• Is there a real environment separation between development and production?
• Which paths are covered by automated tests, and which are not?
• Who can deploy, and what stops an unreviewed change reaching production?

07

Core domain

Observability & Operations

What we are trying to establish

Without observability, every incident becomes an investigation. Teams cannot prove reliability to a customer or an investor if they cannot measure it.

What we examine

Structured logging, error tracking, metrics, tracing on critical flows, alerting thresholds, on-call arrangements, runbooks and the ability to answer questions about production without guessing.

Typical assurance claims

• A material failure is detected by the team before a customer reports it.
• A single request can be traced across the system during an incident.

Questions we ask

• How would the team learn about a failure before a customer reports it?
• Can a single user request be traced across the system?
• What alerts exist, and who receives them?
• What was the last incident, and what changed afterwards?

Overlay

Contextual overlay

Enterprise Assurance

What we are trying to establish

Enterprise procurement asks for evidence, not assurances. It separates two different problems: a control that does not exist, and a control that exists but cannot be demonstrated on request.

What we examine

Role and permission models, audit logging, SSO capability, tenancy model, uptime evidence, architecture and data-flow documentation, vulnerability management and change management records.

Typical assurance claims

• Relevant controls can be demonstrated with evidence, not only described.
• Privileged activity is logged and reviewable.

Questions we ask

• Can the team produce an architecture diagram and data-flow map today?
• Is privileged activity logged and reviewable?
• Does the permission model match what customers will ask for?
• What evidence exists that controls operate, rather than that they were written down?

Overlay

Contextual overlay

AI Assurance

What we are trying to establish

AI features can move from demonstration to something customers depend on without the controls that dependence requires. The failure modes differ from conventional software.

What we examine

Prompt and context handling, data sent to model providers, output validation, tool and action permissions, cost and rate controls, evaluation practice, fallback behaviour and provider dependency.

Typical assurance claims

• AI components cannot take privileged actions outside defined permission and validation boundaries.
• AI output quality is evaluated against defined thresholds rather than judged anecdotally.

Questions we ask

• What customer data reaches a model provider, and under which terms?
• What happens when the model returns an unusable or unsafe output?
• Which actions can an AI component take without human confirmation?
• How is quality measured over time rather than judged anecdotally?

Overlay

Contextual overlay

Product / Operational Instrumentation

What we are trying to establish

Usage evidence supports engineering prioritisation and external conversations. Absent or unreliable instrumentation removes the basis for both.

What we examine

Event coverage on critical journeys, identity resolution, data quality, funnel instrumentation and whether the business can answer usage questions from its own systems.

Typical assurance claims

• Operational and product behaviour can be answered from the organisation's own instrumentation.

Questions we ask

• Can the business measure activation, retention and feature usage today?
• Is the same user identified consistently across the product?
• Which decisions are currently made without data that could be available?