Describe your system. Turn its context into the guarantees, risks and tests that matter.
QA Hub helps teams define quality for their particular product and choose an actionable test strategy. Specialist knowledge and technical constraints are brought together behind a guided experience.
Functional product POCArchitecture defined · implementation roadmap
A music recommendation service, a claims workflow and a generative assistant each need their own definition of quality. Teams must connect domain knowledge, product expectations, operating conditions and verification methods before choosing tests.
QA Hub brings that expertise into the workflow so users can focus on their system and the decisions they need to make.
My contribution
Product definition, development of the product-experience POC, and formalisation of the architecture: knowledge-pack contracts, composition rules, decision records, expert arbitration and a validation protocol.
The working POC demonstrates the product experience. The defined architecture provides the implementation path for the composition engine and traceable decision records.
01 / PRODUCT LOGIC
From context to a quality model.
Describe and confirm
Capture the sector, system type, execution context, device and constraints. The user confirms the structured context and its assumptions.
Compose the knowledge
The Quality Model Engine selects versioned Quality Model Packs and combines applicable risks, properties, metrics and methods through deterministic rules.
Choose the strategy
Turn the model into priorities, verification criteria, tools and artefacts. Surface incompatible requirements for explicit arbitration.
Keep the reasoning
The Quality Evidence Layer records the context, selected packs, references, assumptions, conflicts and decisions in a versioned decision record.
These contracts form the specified decision architecture. Each pack carries specialised knowledge, curated references and an explicit description of its coverage.
02 / WORKED EXAMPLE
A music recommender, on mobile, in production.
Confirmed context
A system with several quality dimensions.
A mobile music app recommends tracks and starts playback. The team needs useful recommendations, reliable listening and an acceptable experience under real network conditions and load.
The relevant model combines music and AI/recommender knowledge with mobile and production constraints.
Knowledge to combine
Each dimension changes the checks.
Music: playback continuity, audio behaviour and streaming resilience.
AI/recommender: relevance criteria, suitable partial oracles and variation between runs.
Mobile and production: device conditions, network interruptions, response budgets and observation of user impact.
1. Translate the model into a test strategy.
Recommendations
Define relevance criteria with the product team and select datasets, properties or human judgements that can evaluate them.
Listening journeys
Exercise playback through device and network changes, including interruption and recovery.
Operational behaviour
Measure response times and errors under the agreed workload, and connect them to the affected user journey.
2. Make conflicts and knowledge gaps visible.
A recommendation method may exceed the mobile response budget. The proposed strategy should expose that conflict, retain the contributing requirements and let the team decide how to resolve it.
Knowledge coverage identifies the dimensions supported by the available packs. A partially supported domain carries its missing dimensions into the decision record.
3. Preserve the reason for each decision.
The record links a recommendation to the confirmed context, the contributing pack and its version, and the curated references supporting it.
An expert can adjust priorities or constraints through the defined arbitration rules. The reason, affected requirements and approval remain attached to the decision.
03 / DESIGN PRINCIPLES
Simple to use. Inspectable in depth.
A reproducible decision core
The specified engine composes a confirmed context and versioned knowledge through deterministic rules. AI assists context extraction and can personalise downstream artefacts. A guided form and structured templates provide fallback paths.
Provider substitution, persistent checkpoints and output validation are part of the target architecture for continuity.
From knowledge to system evidence
The Evidence Layer makes references, assumptions, coverage and expert choices inspectable. Its first implementation is the next product step.
The longer-term vision connects applications, DOM, APIs, documentation, Jira, Confluence, tests and traces to map real journeys and their verification evidence.
04 / PRODUCT PROGRESS
A working experience. A defined implementation path.
Available · product POC
Guided context and artefacts.
A four-question intake covers sector, system type, execution context and device. Five sectors have contextual strategies and structured, exportable artefacts.
The POC uses parameterised templates and simulated agent activity to demonstrate the experience.
Next milestones · implementation and validation
Decision engine and evidence.
Build the Evidence Layer around the POC context.
Implement the pack schema and deterministic composition engine.
Validate decisions and provenance with reference cases.
Add generative personalisation and real tool execution.
The pilot protocol compares composed quality models with an expert prompt and a generic risk-based checklist, using practitioner assessment of useful coverage, relevance, actionability and traceability.