Failure Taxonomy

STR / SEM / PRA / EPI — the four failure domains, twenty-eight failure modes, and five severity levels for classifying validation findings.

Overview

UluOps classifies validation findings into four failure domains with twenty-eight failure modes (seven per domain) for consistent categorization across validators. This taxonomy ensures that findings from different validators can be compared, aggregated, and tracked using a shared vocabulary.

Each finding receives a failure code in the format DOMAIN-MODE/SEVERITY — for example, STR-OMI/C means a critical structural omission.

The Four Domains

STR — Structural

Failures related to the form, format, or organization of an artifact. Structural failures concern whether required elements are present, whether elements are well-formed, and whether elements are consistently organized.

SEM — Semantic

Failures related to the meaning, correctness, or logical consistency of an artifact. Semantic failures concern whether content is factually correct, logically coherent, and free from ambiguity.

PRA — Pragmatic

Failures related to the fitness of an artifact for its intended purpose and context. Pragmatic failures concern whether an artifact serves its stated goals, matches its audience, and remains maintainable over time.

EPI — Epistemic

Failures related to claims, confidence levels, and evidentiary support. Epistemic failures concern whether assertions are appropriately calibrated to available evidence.

Severity Codes

Each failure code ends with a severity indicator:

Mode Disambiguation

These pairs are commonly confused:

Terminology: Findings, Recommendations, and Issues

These three terms describe the same data at different lifecycle stages:

A validator produces findings, which are encoded as recommendations in the API payload, which become tracked issues in the database.

Using the Taxonomy

When saving validation runs, include failure codes in recommendations for cross-agent analytics:

recommendations: [{
  agent: 'code-validator',
  title: 'Missing null check on API response',
  priority: 'suggested',
  severity: 'high',
  failureCode: 'SEM-INC/H',
  failureDomain: 'SEM',
  failureMode: 'INC',
  filePath: 'src/api/client.ts',
  lineNumber: 42,
}]

Compound Code Format

The compound code pattern is {MODE}/{SEVERITY}:

STR-OMI/C   → Critical structural omission
SEM-INC/H   → High-severity semantic incorrectness
PRA-FRA/M   → Medium-severity pragmatic fragility
EPI-OVR/I   → Informational epistemic overclaim

The failure domain is always derivable from the mode prefix — STR-* → STR, SEM-* → SEM, etc.

Distribution in Practice

The taxonomy distribution across the UluOps ecosystem shows a consistent pattern:

Source: UluOps Tracker get_analytics({ metric: "taxonomy_distribution" }), 90-day window as of July 2026 (14,471 classified issues in-window).

STR+SEM still dominate (~64%), reflecting that most validation agents focus on code quality — where structural and semantic issues are the primary failure modes. Two shifts are worth noting against the March 2026 snapshot (when STR led at 36.9% and EPI sat at 9.8%): SEM has overtaken STR as the largest domain, and the EPI share has grown to 13.7% — the predicted consequence of the cognitive-lens analyst and forecaster agents becoming a substantial share of ecosystem runs. That prediction, made in an earlier revision of this page, is so far holding.

Domain Portability

The taxonomy was developed for software validation but is designed to be domain-portable. The four domains (STR/SEM/PRA/EPI) map to any artifact type — a legal contract has structural omissions, semantic ambiguities, pragmatic misalignment, and epistemic overclaims just as code does.

How Portability Works

UluOps uses domain profiles (Domain Profile Schema v1.0.0) to decouple domain vocabulary from the universal taxonomy:

• Each domain defines its own issue types (e.g., legal: deficiency, ambiguity, compliance-gap)
• A tracker mapping resolves domain types to universal types for persistence
• Domain-specific severity descriptions and edge cases replace software defaults
• Terminology adapts to the domain (e.g., artifact → "contract", review_unit → "clause")

The failure domains themselves (STR/SEM/PRA/EPI) remain constant across domains — they describe universal categories of how things go wrong, not domain-specific vocabularies.

Falsifiability

A necessary refinement to the test. "Resists classification" is ambiguous between two very different failures, and only one of them refutes universality. The 28 modes were carved at software's joints (their detection signals are things like "No JSDoc" and "Type mismatch"), so a legal or financial finding failing to land in a mode may just mean the mode vocabulary hasn't been ported — a provisioning gap, not a refutation. The universality claim attaches to the four domains, and the test must discriminate at that level:

• Mode gap (does not refute): annotators agree on the finding's domain (this is structural / this is epistemic) but no existing mode fits. Remedy: extend the domain's mode set through the domain profile — the same way software's modes were originally derived.
• Domain failure (refutes): domain-expert annotators, given the domain definitions but not the software mode examples, cannot agree on which of the four domains a class of findings belongs to at rates meaningfully above chance — or systematically need a category outside the four. That is the four-domain structure failing, not a vocabulary shortfall.

Operationally: run the cross-domain deployment with domain-level annotation agreement as the primary metric and mode-fit as a secondary one. Mode extension is expected and planned; persistent domain-level disagreement is the falsification signal.

This test has not yet been executed. All current data comes from software validation (14,000+ classified issues in the trailing 90 days as of July 2026). The domain profile schema and type mapping infrastructure are implemented, but no non-software agents have been deployed in production. Until cross-domain data exists, the portability claim remains a design hypothesis, not an empirical finding.

Analytics

The taxonomy enables cross-cutting analytics:

• Domain breakdown — What percentage of issues are structural vs semantic?
• Agent matrix — Which agents catch which failure modes? Where are blind spots?
• Trend analysis — Are semantic issues decreasing over time?

Use get_full_taxonomy_analytics (MCP) or client.analytics.getTaxonomy() (SDK) to query taxonomy-level metrics.