UAIF Technical Specification

Document status and notice

UNIFIED AI INCIDENT FRAMEWORK
UAIF™ v1.0

Technical Specification — Final Publication v1.0
TCR-STD-002 | Q2 2026 | Normative errata integrated 14 August 2026 | Licensed under GAISSF Ecosystem Licence (GEL v1.0)

Published by ODA3 Institute | Applied Research & Advisory | AI Security | Standards Development | Certification

Status and Finality Notice

UAIF™ v1.0 is a Final Publication. Final status means the v1.0 normative architecture, controlled vocabulary, machine-readable conformance model, and reference calculation semantics are frozen under ODA3 Institute change control. It does not mean that every sector calibration, legal interpretation, integration pattern, or empirical reliability claim has been validated in production.

Sector-specific calibration, independent inter-rater studies, and broad SIEM/GRC interoperability testing remain validation work. Regulatory trigger logic provides technical routing assistance only. Legal counsel SHALL determine definitive compliance obligations, including EU AI Act Article 73 serious-incident reporting and any GDPR, NIS2, DORA, or sectoral obligations.

1. Executive Summary

UAIF™ provides a machine-readable incident interchange, classification, severity scoring, and conformance architecture for AI incidents and vulnerabilities. It is designed to reduce crosswalk friction across security operations, governance, regulatory routing, and assurance workflows.

1.1A Notably Absent

• No empirical claim that default harm weights are sector-validated.

• No certification, audit authority, or licence to claim UAIF Certified status.

• No legal determination of EU AI Act Article 73, GDPR, NIS2, DORA, or sectoral reporting obligations.

• No universal SIEM/GRC integration warranty across target platforms.

• No proprietary sector calibration packages or confidential pilot datasets.

• No claim that Final Publication status establishes empirical deployment maturity or regulator recognition.

1.2 Primary Outputs

2. UAIF 7-Layer Architecture

Architectural decision: prior L7 AI Control Plane Extensions are merged into L5 for API simplicity. TCR-STD-003 SHALL follow this 7-layer architecture. L7 SHALL NOT be treated as a separate conformance layer in UAIF v1.0.

2.1 Record Type Semantics

record_type SHALL take one of two normative values:

• Incident — a realized event involving an AI system that has produced, or is reasonably assessed to have produced, an adverse operational, security, safety, privacy, societal, or other relevant effect.

• Vulnerability — a weakness, exposure, or susceptible condition that could contribute to an adverse event but is not itself evidence that such an event has occurred.

Unclassified signals, alerts, telemetry items, or investigative leads are not a UAIF record_type. They remain in the originating detection or case-management workflow until sufficient information exists to classify the record as Incident or Vulnerability. Observation is not a UAIF record_type value.

2.2 Profile and Extension Declaration

Every UAIF record SHALL declare profile, identifying its base conformance profile. The normative base values are Core, Enterprise, and Regulatory, where Enterprise extends Core with L3/L4 fields and Regulatory extends Enterprise with extended L6 obligations.

A record MAY additionally declare one or more extensions. UAIF v1.0 defines two extension identifiers: SOC_SIEM (approved ATLAS/security-tooling mapping fields) and AI_Security (selected L5 generative/agentic/control-plane fields). Extensions are additive and SHALL NOT reduce or override the requirements of the selected base profile. Any base profile MAY declare either, both, or neither extension.

3. Adoption Profiles and Conformance

Core Profile implementations SHALL NOT include prohibited L3/L4 fields in the primary payload. Extension-gated fields SHALL NOT appear unless the corresponding extension is declared. Extended data MAY be stored under x_extensions where permitted, but SHALL NOT affect base-profile validation. Custom vocabulary values SHALL use the x_ prefix only where the controlled vocabulary explicitly allows it.

4. Severity Scoring Engine v1.0

UAIF severity scoring draws structural inspiration from CVSS v3.1/v4.0 but is a post-incident classification and routing model. It is not a replacement for vulnerability scoring.

4.1 Context Modifiers

4.2 Normative Calculation

The normative UAIF v1.0 calculation SHALL follow this order: dominant-harm anchor; diminishing context contribution; impact scale using MAX(population, blast radius); inverted temporal confidence reduction; final analytical and presentation scores. Implementations SHALL NOT use collapsed single-score fields or non-normative stakeholder multipliers.

from decimal import Decimal, ROUND_HALF_UP

HARM_WEIGHTS = {
"Physical_Harm": 4.0, "Environmental_Harm": 3.5, "Security_Integrity": 3.5,
"Privacy_Violation": 3.0, "Financial_Loss": 2.5, "Psychological_Harm": 2.0,
"Property_Damage": 2.0, "Reputational_Harm": 1.5
}

CONTEXT_MODIFIERS = {
"Model_Poisoning": 2.0, "RAG_leakage": 1.5, "Prompt_Injection": 1.5,
"Agent_Hijack": 1.5, "Agentic": 1.0, "Adversarial": 0.5
}

def _round_decimal(value, places=1):
quantum = Decimal("1." + ("0" * places)) if places else Decimal("1")
return float(Decimal(str(value)).quantize(quantum, rounding=ROUND_HALF_UP))

def score_to_level(score):
if score < 2.0: return 1
if score < 4.0: return 2
if score < 6.5: return 3
if score < 8.5: return 4
return 5

# Reference implementation applies dominant-harm weighting, diminishing context contribution,
# impact scale, confidence/temporal adjustment, and returns severity_rationale as the canonical audit object.

4.3 Impact Scale and Temporal Adjustment

Impact scale = min(1.8, max(population_multiplier, blast_radius_multiplier)). This prevents double-counting of scale dimensions.

4.4 Rounding and Precision Rule

All decimal scores SHALL use Decimal ROUND_HALF_UP. severity_analytical_score and severity_presentation_score SHALL be represented to one decimal place as a normative semantic/conformance rule. Ratio or internal contribution values MAY be rounded to two decimal places where specified by severity_rationale.

The canonical JSON Schema intentionally does not use multipleOf: 0.1 for score precision. Binary floating-point implementations can produce validator-dependent false negatives for valid decimal values such as 2.8, 5.1, or 9.1. Precision SHALL therefore be verified by the reference implementation or equivalent conformance tooling rather than by JSON Schema multipleOf.

4.5 Severity Matrix

Boundary rule: lower bounds are inclusive; upper bounds are exclusive except Level 5, where 10.0 is inclusive.

5. Regulatory Trigger Logic

UAIF regulatory_trigger is a technical routing flag. It SHALL NOT be treated as a legal determination. EU AI Act serious-incident references SHALL use Article 73. Obsolete EU AI Act incident-reporting proxy references SHALL NOT be used in UAIF v1.0.

6. Sector Taxonomy

The normative sector_code field SHALL use the 19-code NIS2-aligned UAIF enum below. NAICS/NACE identifiers MAY be captured in optional mapping metadata fields such as nace_code_actual or naics_code_actual; they SHALL NOT replace sector_code.

7. Governance, Versioning, and Supporting Documents

8. Licensing and Brand Use

UAIF™, GAISSF™, AI-IRF™, ODA3™, and ODA3 Institute marks are proprietary marks of ODA3 Pvt Ltd. This document is licensed under GEL v1.0. No certification, endorsement, or official conformance status is granted by use of this document or schema alone.

Appendix A: UAIF Core Profile Schema Reference

The normative machine-readable schema is maintained in TCR-STD-003. The schema identifier is: https://schemas.oda3.org/uaif/core/v1.0/uaif-core-v1.0.json

Appendix B: Conditional Validation Rules

Appendix H: Harm Weight Derivation Methodology

Default harm weights are provisional and derived from preliminary incident review and expert elicitation. Target inter-rater reliability for sector validation is ICC >= 0.80 using ICC(2,k), two-way mixed-effects model, absolute agreement, average measures. Sector validation requires >=10 raters and >=30 reference incidents per sector cohort.

Appendix I: Standards Alignment Notes

NIST AI RMF 1.0 is the current alignment basis for GOVERN, MAP, MEASURE, and MANAGE functions. NIST AI 100-2 E2025 may be referenced only for adversarial machine learning taxonomy alignment and not as a successor AI RMF release.

EU AI Act references in UAIF v1.0 use Article 73 for serious incident reporting proxies. Legal counsel determines applicability and reporting timelines.

Appendix J: NACE and NAICS Mapping Guidance

NACE and NAICS codes are mapping metadata only. Implementations SHOULD map primary activity codes to the normative UAIF sector_code enum and retain the original activity code in nace_code_actual or naics_code_actual.

Appendix K: Controlled Vocabulary