Engineering doctrine
Engineering
Twelve principles that determine how systems are engineered here, and the standards that follow from them. They exist to be held against our own work first.
Doctrine
The twelve principles
Each principle is a constraint on how work proceeds. Where a principle and a deadline conflict, the conflict is raised rather than absorbed.
Architecture before implementation
System, data, AI, security and infrastructure structure is decided and recorded before code is written against it.
Specifications before improvisation
Behaviour is specified precisely enough to be built, reviewed and tested without interpretation at the keyboard.
Evidence before claims
Nothing is asserted about a system — internally or publicly — without an artefact that supports it.
Security by construction
Identity, permissions, data boundaries and secrets handling are designed into the architecture, not audited in afterwards.
Production before presentation
A system is judged by how it behaves under real operation, not by how it demonstrates.
Ownership before dependency
The client owns the architecture, the code and the documentation required to operate and change the system.
Measured gates before progression
Each stage has conditions that must be satisfied before the next begins, and stopping remains a valid outcome.
Human accountability over autonomous systems
Consequential decisions retain a human owner. Autonomy is bounded, observable and reversible.
Clarity before complexity
The simplest structure that satisfies the requirement is preferred to the most sophisticated one available.
Maintainability before novelty
Technology is selected for how long it can be operated, not for how recent it is.
Real operation before demo theatre
Evaluation, monitoring and failure behaviour are engineered before a system is described as working.
Traceability before scale
Inputs, decisions and outputs can be reconstructed after the fact before volume is increased.
Standards
How the doctrine is enforced
Principles that are not enforced by process are decoration. These are the mechanisms through which they hold.
- Architecture record
Structural decisions and their rationale are written down, versioned and reviewable later.
- Specification and review
Behaviour is specified, reviewed and only then implemented against the approved definition.
- Automated testing
Regression, integration and behaviour tests run in the delivery pipeline rather than by intention.
- AI evaluation
AI behaviour is measured against defined cases, with guardrails and human review where consequences are material.
- Security engineering
Identity, permission and data boundaries are designed, implemented and re-checked as the system changes.
- Observability
Logging, monitoring and traceability are part of the build, so behaviour in production can be explained.
- Release governance
Changes reach production through a controlled, reversible and recorded process.
- Documentation and handover
Operational documentation is produced so the client can run, audit and change the system without us.
Scrutiny
Built to be examined
The same standards are what make a system defensible under technical due diligence: an architecture that can be explained, decisions that can be traced, tests that can be run, and AI behaviour that can be evaluated rather than described.
What a reviewer can expect to find
- Architecture and decision records available for review
- Traceable change history from specification to release
- Defined evaluation cases for AI behaviour
- Explicit security, privacy and data-handling positions
- Documented operational and recovery procedures
- Client ownership of code, architecture and documentation
Hold the architecture to this standard
Bring a system, a specification or an architecture under pressure. The discussion is technical, and it starts with structure.