Security by design
Standard on relevant work
Security is part of the architecture from the first design decision, rather than a review at the end.
- Authentication and authorisation designed before features
- Role-based and data-level access control
- Least-privilege service accounts and API scopes
- Server-side secrets — never in a client bundle
- Input validation at every boundary
- Audit trails for privileged and automated operations
- Human approval required for consequential automated actions
- Dependency and security maintenance as ongoing work
Observability
Scoped per engagement
When something misbehaves in production, the system can tell you what happened.
- Structured logging around integration points
- Error handling that records context, not just a stack trace
- Traceability from a result back to its source records
- Monitoring appropriate to what the system does
Accessibility
Practised here
Interfaces are operable by keyboard and by assistive technology, and this is tested.
- Semantic structure and landmarks
- Full keyboard operation with visible focus
- Contrast measured against its own background, not assumed
- Reduced-motion respected
- Automated checks in the test suite
Maintainability & testing
Practised here
Correctness is enforced by tests rather than by the memory of whoever wrote it.
- Types that make invalid states unrepresentable
- Tests that fail the build when an invariant breaks
- Code someone else can change six months later
Human control
Standard on relevant work
Automation prepares consequential actions. A person releases them.
- Explicit approval gates on anything that writes back
- What was proposed, approved and executed is recorded
- Permissions on automation, not just on people
Architecture
Practised here
Systems are structured so the next change is possible without a rewrite.
- One source of truth per concern
- Explicit boundaries between layers
- Integration isolated behind interfaces
- Modules that can be replaced independently
Reliable integration
Standard on relevant work
The parts most likely to fail are the parts between systems, so they are engineered for it.
- Retries, timeouts and idempotency where they matter
- Validation before anything is written back
- Explicit handling of the case where a source system disagrees
- Nothing silently dropped
Performance & scalability
Practised here
Performance is a design constraint, measured rather than assumed.
- Work moved off the request path where it belongs in the background
- Query and index design as part of data modelling
- Animation and rendering on the compositor, not the main thread
- Load characteristics understood before scale is promised
Built for discovery
Practised here
Public-facing systems are engineered to be understood by search engines and AI systems — where that is relevant to what the system is.
- Semantic HTML and a correct heading structure
- Structured data and metadata architecture
- Canonicals, sitemap and robots directives
- Server-rendered content rather than text drawn into canvas
- Internal linking and crawlable navigation
- Core Web Vitals treated as an engineering budget