Specification & QA Governance.
An independent source of truth for the platform behind BMI Global Ed's 60 to 80 international education fairs a year: a repository of specifications and tests, kept apart from the application code, that connects what the platform must do to proof that it does it.
A source of truth that outlives any one repo
External vendor engineers and AI coding agents both change the platform, and every change risks drifting from what it is meant to do. The platform takes student registrations and exhibitor bookings and payments for every fair, so that drift reaches real students and universities. This repository holds specifications and tests but no application code. It is the independent record that settles the question, and it outlives any single application repository, vendor or engineer's tenure.
Specification-to-test traceability
Every specification, test case, integration test and unit test matched one-for-one for the exhibitor CRM, checked automatically on every change.
Cross-repository sync
Specification and test content kept consistent automatically across the repositories it governs, whenever any one of them changes.
Guarded AI authoring
An AI agent runs a structured interview on each new requirement, and a separate challenge step questions it, before the specification, test cases and automated tests are drafted. Hard guardrails keep it away from application source code.
Drift triage
A documented, recurring process that catches specification/code mismatches and converts each one into a prioritised action item for backend, frontend or QA.
A hierarchy of truth
The specifications are the reference everyone works from. When code and specification disagree, a documented rule applies: the code wins, and the specification is corrected so the reference stays true.
Governed issue intake
No engineering work accepted without an explicit specification reference, a named owner, and linked test-coverage evidence.
From requirement to verified proof
The repository runs no service of its own. Its structure is the contract: every specification (SPEC) carries matching identifiers for its test case (TC), integration test (IT) and unit test (UT). That structure is checked automatically on every change and used by both the QA team and the AI agents that draft new specifications.
What I directed
I directed BMI's QA team and instituted the spec-driven, test-driven practice this repository supports, entirely through verbal direction and written specifications rather than through code.
- Set the direction for a QA/specification-governance system covering 96 specifications across seven directories that mirror the platform's seven modules one-for-one, with a complete, CI-enforced traceability chain, specification to test case to integration test to unit test, verified matched one-for-one for the exhibitor CRM.
- Set the direction for a bidirectional documentation-sync architecture keeping specification and test content consistent across the repositories it governs, triggered automatically whenever any of them changes.
- Directed the QA team's work through verbal direction and written specifications, and instituted the spec-driven, test-driven engineering practice these specifications support: developers feed them to AI coding agents to drive implementation.
- Instituted hard guardrails preventing AI coding agents from touching application source code, within a governed authoring pipeline that generates specifications, test cases and automated tests from a structured requirement interview.
- Established a spec-vs-implementation triage process that catches and resolves drift on a documented cadence, converting each mismatch into a prioritised action item.
- Improved the experience of the vendor engineering team building on the platform by directing specification governance with a CI-checked chain from specification to test, so vendor disputes that once took multiple email threads now take none.
Tech stack
Say hello.
Message sent.
Thanks for getting in touch.