Hongik Ingan (εΌηδΊΊι)
"Benefit All Humanity"
A standardised data format is the bedrock of interoperability. The WIA Emotion AI Data Format ensures that any conformant system can share and process emotion data with any other. This chapter treats Phase 1 β the most foundational of the four phases β in depth and provides field specifications, JSON-Schema validation rules, worked examples for all four modalities, and pseudonymisation guidance that aligns with the principal data-protection regimes (GDPR, CCPA / CPRA, BIPA, PIPA, and PIPL).
Phase 1 defines the JSON-based data format used to represent the output of an emotion-analysis system. The format makes the following possible.
JSON is adopted as the primary format because it is human-readable, supported by the standard library of nearly every programming language, paired with rich automatic-validation tooling (JSON Schema, OpenAPI), and natively compatible with web and mobile environments. Conversion guides for XML (W3C EmotionML), Protocol Buffers, and MessagePack are provided in the annexes for environments that require an alternative wire format.[1]
| Goal | Implementation |
|---|---|
| Simplicity | JSON format; clear field names |
| Completeness | All emotion models and modalities supported |
| Extensibility | Prefix rule for user-defined fields (x_ prefix) |
| Validatability | Authoritative JSON Schema for automatic checking |
| Precision | High-resolution timestamps and numeric values |
The design goals must balance one another: a format that emphasises simplicity at the expense of completeness invites a proliferation of vendor-specific extensions; a format that pursues completeness at the expense of simplicity has a steep learning curve and slow adoption. WIA Phase 1 converts each goal into a measurable indicator (number of mandatory fields, schema-validation pass rate, extension-prefix conformance, character-set fidelity, and timestamp resolution) so that the balance can be evaluated rather than asserted.
{
"$schema": "https://wiastandards.com/emotion-ai/v1/schema.json",
"format": "WIA-EMOTION-AI-v1.0",
"timestamp": "2026-05-01T10:30:00.000Z",
"subject_id": "user_12345",
"session_id": "sess_abc123",
"modality": "facial",
"emotions": {
"primary": {
"label": "happiness",
"confidence": 0.87
},
"secondary": {
"label": "surprise",
"confidence": 0.23
},
"all": [
{ "label": "happiness", "confidence": 0.87 },
{ "label": "surprise", "confidence": 0.23 },
{ "label": "neutral", "confidence": 0.15 },
{ "label": "sadness", "confidence": 0.05 },
{ "label": "anger", "confidence": 0.03 },
{ "label": "fear", "confidence": 0.02 },
{ "label": "disgust", "confidence": 0.01 }
]
},
"dimensions": {
"valence": 0.72,
"arousal": 0.45,
"dominance": 0.55
},
"action_units": [
{ "au": "AU6", "intensity": 0.8, "name": "Cheek Raiser" },
{ "au": "AU12", "intensity": 0.9, "name": "Lip Corner Puller" },
{ "au": "AU1", "intensity": 0.3, "name": "Inner Brow Raiser" }
],
"face": {
"detected": true,
"bbox": { "x": 120, "y": 80, "width": 200, "height": 250 },
"landmarks": 68,
"pose": { "pitch": 5.2, "yaw": -3.1, "roll": 1.2 }
},
"metadata": {
"model_version": "2.1.0",
"model_name": "WIA-EmotionNet",
"processing_time_ms": 45,
"device_id": "cam_001",
"culture_context": "en-US"
}
}
The example shows the most common output of the facial modality. Five top-level objects (emotions, dimensions, action_units, face, and metadata) compose the core payload; downstream systems may consume only the parts they need. Average message size is one to two kilobytes uncompressed, falling to roughly 0.4 to 0.8 kilobytes after gzip. At 30 fps streaming, the bandwidth cost of the analysis-output messages is negligible compared with the camera video itself.
| Field | Type | Required? | Description |
|---|---|---|---|
| format | string | required | Format identifier: "WIA-EMOTION-AI-v1.0" |
| timestamp | string (ISO 8601) | required | Analysis timestamp, RFC 3339 profile |
| subject_id | string | optional | Subject identifier β pseudonymisation strongly recommended |
| session_id | string | optional | Session identifier |
| modality | string | required | Input type: facial, voice, text, biosignal, multimodal |
subject_id must, in any environment subject to GDPR Article 9, PIPA Article 23, BIPA, or CPRA "sensitive personal information" rules, be generated through a pseudonymisation procedure that substantively prevents re-identification. The recommended forms are: a UUID v4 (RFC 9562); an HMAC-derived hash with key separation (RFC 2104); or the output of the regulator's published pseudonymisation procedure. Plaintext personal identifiers β legal names, national identification numbers, email addresses β must not appear in this field.[2]
emotions Object| Field | Type | Required? | Description |
|---|---|---|---|
| emotions.primary | object | required | Highest-confidence emotion |
| emotions.primary.label | string | required | Emotion label (happiness, sadness, β¦) |
| emotions.primary.confidence | number (0β1) | required | Confidence score |
| emotions.secondary | object | optional | Second-highest-confidence emotion |
| emotions.all | array | optional | Full distribution over emotion labels |
Basic emotions (mandatory support): "happiness" - joy, pleasure, satisfaction "sadness" - grief, sorrow, depression "anger" - displeasure, frustration, fury "fear" - anxiety, dread "disgust" - revulsion, rejection "surprise" - astonishment, wonder "neutral" - no strong emotion detected Extended emotions (optional): "contempt" - disdain, dismissal "confusion" - perplexity, bewilderment "interest" - curiosity, engagement "boredom" - disinterest, ennui "excitement" - high-arousal positive "anxiety" - worry, uneasiness Locale-specific extension labels (regional Annexes): Each regional annex may register additional labels that capture culturally specific affect categories (for example, sustained longing or culturally specific forms of grief). Such labels are declared with an English key, a display name, a typical V-A range, and a citation, so that systems unfamiliar with the category can still interpret the data conservatively.
dimensions Object| Field | Type | Range | Description |
|---|---|---|---|
| dimensions.valence | number | β1.0 to +1.0 | Pleasantness |
| dimensions.arousal | number | β1.0 to +1.0 | Activation level |
| dimensions.dominance | number | β1.0 to +1.0 | Optional third dimension (PAD model) |
The two-dimensional Valence-Arousal pair follows Russell's circumplex (Russell, 1980).[3] The optional dominance dimension follows Mehrabian's PAD model (Mehrabian, 1996); systems that do not estimate dominance simply omit the field, which is preferable to emitting a placeholder value.[4]
action_units ArrayEach entry in action_units identifies a FACS Action Unit, its intensity (a value in the range 0.0 to 1.0, mapped to the FACS five-grade scale per Table 3-5), and an optional human-readable name. AU output exposes the analytic evidence behind a discrete-label decision, supporting the EU AI Act's transparency and human-oversight obligations and the relevant medical-grade explainable-AI guidance.
{
"format": "WIA-EMOTION-AI-v1.0",
"timestamp": "2026-05-01T10:30:00.000Z",
"subject_id": "anon_8a72c1",
"modality": "voice",
"emotions": {
"primary": { "label": "anger", "confidence": 0.79 }
},
"dimensions": { "valence": -0.61, "arousal": 0.74 },
"voice_features": {
"pitch_mean_hz": 232.4,
"pitch_std_hz": 42.7,
"intensity_db": 72.5,
"speech_rate_wpm": 178,
"voice_quality": "tense"
},
"metadata": { "model_version": "2.1.0", "sample_rate_hz": 16000 }
}
{
"format": "WIA-EMOTION-AI-v1.0",
"timestamp": "2026-05-01T10:30:00.000Z",
"modality": "text",
"input_text": "I cannot believe how amazing this is!",
"emotions": {
"primary": { "label": "happiness", "confidence": 0.93 }
},
"dimensions": { "valence": 0.91, "arousal": 0.74 },
"sentiment": { "polarity": "positive", "score": 0.95 },
"text_features": {
"language": "en",
"tokens": 9,
"sarcasm_detected": false
}
}
{
"format": "WIA-EMOTION-AI-v1.0",
"timestamp": "2026-05-01T10:30:00.000Z",
"modality": "biosignal",
"biosignals": {
"heart_rate_bpm": 78,
"hrv_rmssd_ms": 42.3,
"eda_microsiemens": 7.2,
"respiration_rate_brpm": 14
},
"dimensions": { "valence": -0.18, "arousal": 0.62 },
"stress_index": 0.71,
"engagement": 0.55
}
{
"format": "WIA-EMOTION-AI-v1.0",
"timestamp": "2026-05-01T10:30:00.000Z",
"modality": "multimodal",
"fusion": {
"strategy": "late",
"weights": { "face": 0.40, "voice": 0.25, "text": 0.20, "biosignal": 0.15 }
},
"emotions": {
"primary": { "label": "anger", "confidence": 0.83 }
},
"per_modality": {
"face": { "label": "anger", "confidence": 0.78 },
"voice": { "label": "anger", "confidence": 0.91 },
"text": { "label": "frustration", "confidence": 0.62 },
"biosignal": { "arousal": 0.74 }
}
}
Phase 1 ships an authoritative JSON Schema (Draft 2020-12) at https://wiastandards.com/emotion-ai/v1/schema.json.[5] The schema is referenced from the $schema field of every conformant message and may be processed by any Draft 2020-12 validator (Ajv, jsonschema, gojsonschema, and others). A worked example of validation in three popular runtimes is given below.
# Python β jsonschema
from jsonschema import validate, ValidationError
import json, urllib.request
with urllib.request.urlopen(
"https://wiastandards.com/emotion-ai/v1/schema.json") as r:
schema = json.load(r)
validate(instance=message, schema=schema)
// Node.js β Ajv
import Ajv2020 from "ajv/dist/2020.js";
const ajv = new Ajv2020({allErrors: true, strict: false});
const validate = ajv.compile(schema);
if (!validate(message)) console.error(validate.errors);
// Go β santhosh-tekuri/jsonschema
sch, _ := jsonschema.Compile(
"https://wiastandards.com/emotion-ai/v1/schema.json")
if err := sch.Validate(message); err != nil { /* report */ }
Validation passes are a strict precondition for conformance. A failed validation result is itself emitted as a structured error object containing the field path, the rule that was violated, and a human-readable message β supporting both automated continuous-integration checks and end-user diagnostics.
| Pattern | Form | Re-identification risk | Maps to |
|---|---|---|---|
| UUID v4 | Random 128-bit identifier | Low (no link to source) | GDPR Recital 26; PIPA Enforcement Decree |
| HMAC-SHA-256 hash | Keyed hash with rotated secret | Low if key separation is enforced | NIST SP 800-188 (de-identification) |
| Tokenisation | Token issued by a separate authority | Very low | ISO/IEC 27018; PIPA Enforcement Decree Β§25-2 |
| Plaintext PII (forbidden) | Legal name, ID number, email | High β non-conformant | Conformance violation |
The pseudonymisation pattern is selected at deployment time and recorded in the metadata.pseudonymisation_method field so that auditors can trace which procedure was used for each record. ISO/IEC 27018 (PII protection in public clouds) and NIST SP 800-188 (de-identification of personal information) provide the procedural reference.[6]
The format identifier in the format field follows Semantic Versioning 2.0 (SemVer 2.0).[7] Major-version increments may break compatibility and are accompanied by a published conversion guide; minor-version increments preserve backwards compatibility; patch-version increments are reserved for documentation clarification. Implementers should reject messages whose major version is greater than the version they support, in line with the standard rule for evolving JSON formats.
The Korean edition of this volume contains additional content addressing the Korean operating environment in detail: the Korean Personal Information Protection Act (PIPA) Enforcement Decree Β§25-2 pseudonymisation procedure, a worked example of mapping between WIA Phase 1 emotion labels and Korean-language affect lexicon (with attention to culturally specific affect categories such as sustained-relational attachment, embarrassment, longing, and culturally specific forms of grief), the Korean Standard Classification of Diseases (KCD) cross-walk for medical-grade biosignal labelling, and a worked alignment with the Korean cyber-security agency PIMS / ISMS-P certification format requirements.
This English edition deliberately abstracts those passages. Where the Korean edition cites specific named Korean statutes, agency tools, or enterprise scenarios, the English edition refers in general terms to "the relevant national data-protection authority", "the relevant national cyber-security agency self-assessment toolkit", "the locally applicable disease classification", and "leading domestic universities, government agencies, telecom operators, and platform companies". The conformance requirements themselves are identical between the two editions.
Seven key takeaways.
$schema field and the validators that consume it.Chapter 5 turns to Phase 2 β the API Interface β which defines the REST endpoints and method signatures that transport Phase 1 messages between systems. Where Phase 1 specifies the shape of the data, Phase 2 specifies how systems exchange that data. The interaction between the two phases β and the sequence in which adopters typically implement them β is treated next. The standard's evolution roadmap is recorded in the public GitHub repository.[99]
WIA-Official/wia-standards-public/tree/main/emotion-ai. The standard's evolution roadmap, revision history, and SDK source code are maintained openly in this repository, where the WIA standards committee records its formal verification of all primary sources cited in this chapter. β