A complete quality cycle, operated on your product.

Managed Quality Engineering. Refinement, agentic testing, automation and CI/CD operated by UPEX with human accountability, and production observation up to whatever maturity level makes sense for your product.

Request an initial assessment

See how the IQL works

What UPEX operates, how it is engaged and who decides, to read at your own pace or share

// What UPEX operates

Operated

Prevention01 · refinementOperated
Early Detection02 · agentic testingOperated
Continuous Detection03 · automation and CIOperated
Production Observation04 · depends on maturityDepends on product

01Assessment
02Setup
03Operation
04Continuous improvement

// The problem

Five lines your engineering team has already said

None of these get fixed with more hours. They get fixed with a quality cycle someone operates end to end.

«Regression eats the week before every release.»
And when something urgent shows up, what gets cut is exactly what breaks later.
«The pipeline has been red for two weeks. We just rerun it and it passes.»
Nobody looks at the reports anymore. You have automation, but you don't trust it.
«We only test through the interface.»
Data bugs and broken contracts between services get discovered in production.
«We bought AI licenses for the team and we're not seeing a return.»
Nobody knows how to give the agent context, or when to distrust what it returns.
«AI-generated code grows faster than test coverage.»
Every sprint brings in more code than the team can review, and testing doesn't keep pace.
None of these is a problem of effort. They're problems of method, and method can be operated.

// What UPEX operates

Four layers, from refinement to production

The IQL read as outcomes. Each layer says what changes in your process and what your team gets; how far each product goes is decided by the initial assessment.

01 · PreventionStages Shift-Left · Planning
QA joins refinement: your stories reach the sprint with verifiable criteria and an acceptance plan.
02 · Early DetectionStages Execution · Reporting · Documentation
Early detection: your team gets the bugs before the PR, not after the release.
03 · Continuous DetectionStages Documentation · Automation · Regression
Regression in CI your team can believe in: only what proved its value gets automated.
04 · Production ObservationStages Observation
Production as the source of the quality strategy, as far as your infrastructure allows.

The IQL defines what to observe and what to improve; the maturity level defines how far to implement Late Game; the concrete targets are defined by each product.

What do you want to do with the IQL?

UPEX GalaxyLearn it
UPEX SatelliteHire people trained in it

See the executive view of the method

// How you engage us

Four models, one sequence

You start with the initial assessment. What follows depends on what the assessment finds and on what your team wants to keep operating on its own.

Model	What you get
01 · Entry pointInitial assessment	A risk map of your product and a written recommendation on what to change first. Risk map of the product and its delivery process Analysis of current coverage, manual and automated Review of the pipeline and recent incidents Written recommendations, with an adoption order
02 · ImplementationIQL Setup	The quality cycle running on your product, with your team involved from day one. Agentic context over your repository, your tracker and your API Automation with traceability to every story Quality gates in your CI Execution reports engineering can actually read Documentation and adoption with the team
03 · Recurring operationMonthly operation	Every story in the sprint ships with coverage, and the regression suite doesn't degrade. Coverage for every story in the sprint First-level triage of the bugs found Review of the reports from every run Participation in refinement Maintenance of the automation
04 · LeadershipFractional QA Lead	Senior quality judgment on a part-time basis, without opening a headcount. Product quality criteria High-level refinement with product and engineering Interface with technical leadership Final review of what ships Asynchronous whenever possible

Scope and timelines are agreed per product, after the initial assessment.

// How it works

From assessment to continuous improvement

One cycle, four moments. None of them requires your team to change tools to get started.

01
Assessment
Read access to your repository, tracker and CI, short conversations with the team, and a risk map with a written recommendation.
02
Setup
UPEX sets up the method on your stack: context for the agents, automation, CI gates and reports, with your team involved.
03
Operation
Async communication in your channel, refinement of every story and a report for every cycle; it all lives in your tracker and your repository.
04
Continuous improvement
What comes back from the environments you define feeds the next cycle: what to observe, what to test and what to automate.

Everything produced is yours: code, cases, artifacts and configuration live in your systems, not UPEX's.

// Who does what

Agents that execute, people who answer for it

Quality Engineering operated with AI and human accountability. Every stage of the method declares what the agent executes, what a person signs off, and what evidence remains. No agent decides for your team.

01
Agent executes.
Executor · Verifier · Guardian
They execute the work of every stage under the guardrails: story analysis, coverage, CI execution, suite maintenance. They propose; they don't sign off.
02
Evidence proves.
QA Analyst · QA Automation Engineer
They oversee every run, review the evidence, and do first-level triage.
03
Human owns the decision.
QA Lead
Owns the quality criteria and the final call: what gets prioritized, what gets automated, what gets approved.

Agents run what's repeatable. Evidence backs every conclusion. A person signs off on every decision.

The agent's limits

They're part of the method, not a sales promise: they hold the same in the Dojo and in your product.

Read
The agent reads code, API schema (via MCP), tracker and data with read-only credentials. It never reads production secrets.
Write
It writes to its own branches, to the QA artifacts in the tracker and to its own reports. It never writes directly to main or to the business data of the product under test.
Approval
Any transition that changes the business state of a story (approve, reject, close) is signed by a person. The agent proposes; it never signs.
Secrets
Tokens live in environment variables and in the CLI's own login, never hardcoded in a prompt or a skill.
Validation
No conclusion enters an artifact without reproducible evidence: a command, a screenshot, a log, a diff.
Traceability
Every artifact and every test the agent produces links back to the item that requested it. Nothing gets created loose.
Checkpoints
Skills don't run end to end without stopping: every stage has a point where a person reviews before the agent keeps going.

// The method, by layer

What belongs to the IQL and what belongs to your stack

The method splits into three layers so nobody assumes it requires a specific tracker, framework or CI provider.

01
IQL Core
The principles and the flow that don't change no matter the stack, the tracker or the client.
02
IQL Implementation Standard
What UPEX prescribes or recommends when implementing it: patterns, tools and AI guardrails.
03
Environment Integrations
What your environment brings and what the method integrates with: tracker, repository, CI, chat, observability.

The IQL doesn't require migrations without technical justification.

The IQL doesn't require replacing the client's ecosystem. It requires the functional equivalent to exist: a tracker with a workflow, a CI that runs on every PR and, for Late Game, a source of production observation.

Tools by layer and decision level

Every tool carries its decision level and the reasoning. What says "the client brings it" gets integrated; what says "recommended" changes with a technical evaluation.

Tool	Layer	Decision	Why
KATA	Implementation Standard	RECOMMENDED	It's the architecture that makes every ATC traceable to its story (`@atc('KEY')`), and the one the boilerplate's skills know how to operate. When UPEX builds the automation from scratch it's used as is; on a framework the client keeps, its invariants (layers, dependency injection, decorators) are applied via `/adapt-framework`, without rewriting it.
Playwright	Implementation Standard	RECOMMENDED	Default when UPEX automates from scratch: the boilerplate and KATA's layer 2 assume it. It isn't mandatory, because the IQL doesn't require migrations without technical justification: an existing mature stack (Cypress, WebdriverIO) gets evaluated at the start and is kept, adapted, or migrated in stages.
Xray	Implementation Standard	ADAPTABLE	The TMS mode UPEX operates with (`jira-xray`): the story's coverage comes natively from the ATS. The boilerplate starts in `jira-native` (`tms_cli: null`) and that mode is supported; another TMS (TestRail, Zephyr) gets evaluated as an adaptation. The initial assessment decides the mode, not the method.
Agentic harness (Claude Code, OpenCode, Codex)	Implementation Standard	ADAPTABLE	The boilerplate's skills, commands and MCPs run on Claude Code, OpenCode (any LLM) or Codex, and adapt to any other harness. The method lives in the skills (markdown), not in the agent: changing harness changes speed and ergonomics, not the flow.
MCPs (OpenAPI, database, tracker, browser)	Implementation Standard	ADAPTABLE	They're how the agent reads schema, data and tracker; which ones connect depends on the client's stack. Boilerplate rule: the MCP reads, it never executes (the API is exercised with curl and the CLI's token), and a configured MCP stays red until it actually responds.
Docker	Implementation Standard	RECOMMENDED	Reproducibility of the Playwright run in CI with the official image. If the client's CI already provides runners with browsers, it gets adapted.
API client (Postman, Bruno, curl)	Implementation Standard	ADAPTABLE	Exploration of the API leg of the Trifuerza. The boilerplate uses OpenAPI MCP + curl; any equivalent client works.
k6	Implementation Standard	ADAPTABLE	Only when the performance attribute enters by risk in Step 1. It is not part of the Dojo and is not promised in the offer to companies.
Jira (or equivalent tracker)	Environment Integration	CLIENT-CONTROLLED	The tracker belongs to the client. The IQL requires a workflow with the states and transitions of `iql.jiraStates`; today the Implementation Standard only has Jira implemented (`.agents/jira-workflows.json`), so Azure DevOps or another tracker is adaptation work evaluated at the start.
Confluence (or team wiki)	Environment Integration	CLIENT-CONTROLLED	Wherever the client's documentation lives. QA artifacts live in the tracker, not in the wiki.
GitHub / GitLab (repository and pull requests)	Environment Integration	CLIENT-CONTROLLED	The repository and the pull request flow come from the client. The standard requires one branch per story and a reviewed PR.
GitHub Actions (or equivalent CI)	Environment Integration	CLIENT-CONTROLLED	The CI comes from the client (GitHub Actions, GitLab CI, Jenkins). The standard requires the ATCs to run on every PR; the boilerplate's reference pipeline is written for GitHub Actions.
Slack / Teams	Environment Integration	CLIENT-CONTROLLED	CI notification and alert channel. The IQL doesn't depend on which one.
Sentry / Grafana / Datadog	Environment Integration	CLIENT-CONTROLLED	Late Game observes with whatever the client already has. The IQL defines what to observe; the tool is defined by the environment. Prerequisite for the Production Observation level.
UptimeRobot (or equivalent uptime monitor)	Environment Integration	CLIENT-CONTROLLED	Any equivalent uptime monitor.
Progressive delivery / feature flags	Environment Integration	CLIENT-CONTROLLED	Prerequisite for canary and A/B. Without this, steps 11 and 12 don't get implemented.
Chaos tools (Gremlin, Litmus, custom scripts)	Environment Integration	CLIENT-CONTROLLED	Prerequisite for step 14.

See the 17 tools

KATA
Implementation StandardRECOMMENDED
It's the architecture that makes every ATC traceable to its story (@atc('KEY')), and the one the boilerplate's skills know how to operate. When UPEX builds the automation from scratch it's used as is; on a framework the client keeps, its invariants (layers, dependency injection, decorators) are applied via /adapt-framework, without rewriting it.
Playwright
Implementation StandardRECOMMENDED
Default when UPEX automates from scratch: the boilerplate and KATA's layer 2 assume it. It isn't mandatory, because the IQL doesn't require migrations without technical justification: an existing mature stack (Cypress, WebdriverIO) gets evaluated at the start and is kept, adapted, or migrated in stages.
Xray
Implementation StandardADAPTABLE
The TMS mode UPEX operates with (jira-xray): the story's coverage comes natively from the ATS. The boilerplate starts in jira-native (tms_cli: null) and that mode is supported; another TMS (TestRail, Zephyr) gets evaluated as an adaptation. The initial assessment decides the mode, not the method.
Agentic harness (Claude Code, OpenCode, Codex)
Implementation StandardADAPTABLE
The boilerplate's skills, commands and MCPs run on Claude Code, OpenCode (any LLM) or Codex, and adapt to any other harness. The method lives in the skills (markdown), not in the agent: changing harness changes speed and ergonomics, not the flow.
MCPs (OpenAPI, database, tracker, browser)
Implementation StandardADAPTABLE
They're how the agent reads schema, data and tracker; which ones connect depends on the client's stack. Boilerplate rule: the MCP reads, it never executes (the API is exercised with curl and the CLI's token), and a configured MCP stays red until it actually responds.
Docker
Implementation StandardRECOMMENDED
Reproducibility of the Playwright run in CI with the official image. If the client's CI already provides runners with browsers, it gets adapted.
API client (Postman, Bruno, curl)
Implementation StandardADAPTABLE
Exploration of the API leg of the Trifuerza. The boilerplate uses OpenAPI MCP + curl; any equivalent client works.
k6
Implementation StandardADAPTABLE
Only when the performance attribute enters by risk in Step 1. It is not part of the Dojo and is not promised in the offer to companies.
Jira (or equivalent tracker)
Environment IntegrationCLIENT-CONTROLLED
The tracker belongs to the client. The IQL requires a workflow with the states and transitions of iql.jiraStates; today the Implementation Standard only has Jira implemented (.agents/jira-workflows.json), so Azure DevOps or another tracker is adaptation work evaluated at the start.
Confluence (or team wiki)
Environment IntegrationCLIENT-CONTROLLED
Wherever the client's documentation lives. QA artifacts live in the tracker, not in the wiki.
GitHub / GitLab (repository and pull requests)
Environment IntegrationCLIENT-CONTROLLED
The repository and the pull request flow come from the client. The standard requires one branch per story and a reviewed PR.
GitHub Actions (or equivalent CI)
Environment IntegrationCLIENT-CONTROLLED
The CI comes from the client (GitHub Actions, GitLab CI, Jenkins). The standard requires the ATCs to run on every PR; the boilerplate's reference pipeline is written for GitHub Actions.
Slack / Teams
Environment IntegrationCLIENT-CONTROLLED
CI notification and alert channel. The IQL doesn't depend on which one.
Sentry / Grafana / Datadog
Environment IntegrationCLIENT-CONTROLLED
Late Game observes with whatever the client already has. The IQL defines what to observe; the tool is defined by the environment. Prerequisite for the Production Observation level.
UptimeRobot (or equivalent uptime monitor)
Environment IntegrationCLIENT-CONTROLLED
Any equivalent uptime monitor.
Progressive delivery / feature flags
Environment IntegrationCLIENT-CONTROLLED
Prerequisite for canary and A/B. Without this, steps 11 and 12 don't get implemented.
Chaos tools (Gremlin, Litmus, custom scripts)
Environment IntegrationCLIENT-CONTROLLED
Prerequisite for step 14.

What each level means

REQUIRED: Without this, it isn't IQL the way UPEX implements it.
RECOMMENDED: UPEX's default; it changes with a technical evaluation that justifies it.
ADAPTABLE: More than one supported option exists; the initial assessment picks one.
CLIENT-CONTROLLED: The client's environment brings it; the IQL integrates with it.

// What we can show

The method is public, and it already runs

We don't publish client metrics yet. What you can see: the framework we operate with, the full methodology, and screenshots from the reference project.