# S-Code / ISO-Taste Complete AI Specification

- Framework key: `sensory`
- Framework type: sensory event / reference encoding standards family
- Public version: 1.0
- Release status: Public Schema / Registry
- Human reading page: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory
- Conformance: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/conformance
- Public resource: https://aistory-archive.pages.dev/standards/sensory.schema.json
- Public resource: https://aistory-archive.pages.dev/standards/sensory.example.json
- Public resource: https://aistory-archive.pages.dev/standards/sensory.registry.json
- Known public limit: The hub defines no extra shared levels; the detailed specification governs

This document is generated directly from the current public specification/reader source for AI retrieval, citation, comparison, and evaluation. It does not rewrite the public Schema or promote teaching presentation into formal measurement or operational permission.

## Use and interpretation rules

- S-Code describes sensory events; ISO-Taste manages references, codes, cultural/regional variants, calibration, and cross-system recognition. They may map to one another without becoming the same system.
- T/O/X/M/P/H/A/V are product/event description families; U is a separate personal-calibration layer rather than another sensory-intensity modality.
- The public measurement_status remains measured / estimated / inferred; these epistemic states are not interchangeable.
- Human-page 0–100 radar values are relative teaching salience, not laboratory measurement, sensory intensity, deliciousness, or cross-food quality scores.
- A reference is a versioned, traceable comparison coordinate rather than a best-food or cultural ranking.

## Complete public specification topics

## 01. Scope

- Stable topic slug: `scope`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/scope

S-Code / ISO-Taste exchanges sensory targets and traceable references without reducing taste preference to one universal score.

### Scope

This standards family exchanges what a sensory product or event should present and how it can be compared with traceable references. It does not claim that deliciousness is reducible to one score or that population-average preference is the final judgment for an individual.

## 02. Division of Roles

- Stable topic slug: `division-of-roles`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/division-of-roles

S-Code describes sensory events while ISO-Taste manages references, codes, cultural variants, calibration, and cross-system recognition.

### S-Code and ISO-Taste

S-Code is a sensory description and exchange schema. It describes when and how a food or sensory sample should present taste, smell, texture, mouthfeel, temperature, and sound. ISO-Taste manages reference profiles, public short codes, semantic structural codes, cultural / regional variants, calibration, and cross-system recognition. They can map to one another without becoming the same system.

## 03. Nine S-Code Families

- Stable topic slug: `s-code-families`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/s-code-families

S-Code uses nine coding families for taste, olfaction, texture, mouthfeel, trigeminal stimulation, heat, acoustics, variation, and user calibration; U is a calibration layer rather than a sensory modality.

### Nine Coding Families

T/O/X/M/P/H/A/V describe sensory or product/event variation; U is a separate personal-calibration layer and should not be treated as another sensory-intensity modality.

**S-Code Family Legend**

| Code | Name | Role | Class |
| --- | --- | --- | --- |
| T | Taste | Taste targets and temporal behavior. | Sensory |
| O | Olfaction | Aroma family, release, and after-aroma. | Sensory |
| X | Texture & Fracture | Structure, fracture, elasticity, and physical change during chewing. | Sensory |
| M | Mouthfeel | Viscosity, smoothness, dryness, and other oral physical sensations. | Sensory |
| P | Trigeminal Stimulation | Heat, cooling, pungency, and other non-taste stimulation. | Sensory |
| H | Heat & Thermal History | Serving temperature, melting, and thermal history. | Sensory |
| A | Acoustics | Bite, fracture, and chewing sound. | Sensory |
| V | Variation | Controlled batch, time, process, or presentation variation. | Variation |
| U | User Calibration | Personal calibration profile and output adjustment. | Calibration layer |

## 04. Sensory Packet Data Model

- Stable topic slug: `packet-data-model`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/packet-data-model

One shared record keeps identity, version, measurement status, and provenance while S-Code sensory events and ISO-Taste reference data remain separate.

### Core Principle

A sensory packet first preserves shared identity, version, measurement status, provenance, and permissions, then branches by data role into S-Code, ISO-Taste, or a mapping between them. This keeps common context together without collapsing sensory events and reference data into one object.

**Common Packet Anatomy**

| Reader purpose | Machine key | Role |
| --- | --- | --- |
| Which record is this? | identifier | Packet identity |
| Which packet version is this? | version | Packet version |
| Which controlled vocabulary / code registry applies? | registry_version | Registry binding |
| What role does this record play? | system_role | Distinguishes S-Code, ISO-Taste, or mapped-profile |
| Was the data measured, estimated, or inferred? | measurement_status | Preserves epistemic status |
| Where did the data come from? | provenance | Preserves traceable origin |
| How may it be used? | rights_consent | Preserves rights and consent limits |

**Role-Specific Blocks**

| Data role | Machine structure | Required content |
| --- | --- | --- |
| S-Code sensory event | s_code | T / O / X / M / P / H / A / V / U |
| ISO-Taste reference | iso_taste | public_code / structural_code, reference_profile, cultural / regional context, and calibration notes |
| Cross-system mapping | mapped-profile | Contains s_code, iso_taste, and at least one mapping |
| Conformance result | conformance | Separate schema, reference, and experiential assessments; one passing layer does not imply another |

## 05. Required Fields and Status

- Stable topic slug: `required-fields`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/required-fields

Every sensory record needs basic identity, version, measurement status, provenance, and permission information; its purpose then determines whether S-Code or ISO-Taste content is required.

### Start with Shared Requirements

Whether a record belongs to S-Code, ISO-Taste, or a mapping between them, it first preserves a shared set of fields. Role-specific blocks are added afterward, and an unperformed conformance check is marked explicitly rather than implied by omission.

**Fields Required for Every Role**

| Reader purpose | Machine key |
| --- | --- |
| Record identity | identifier |
| Packet version | version |
| Registry version | registry_version |
| System role | system_role |
| Measurement / estimate / inference status | measurement_status |
| Provenance | provenance |
| Rights and consent | rights_consent |
| Conformance record | conformance |

**Requirements by system_role**

| system_role | Required content | Condition |
| --- | --- | --- |
| s-code | s_code | At least one S-Code family is populated |
| iso-taste | iso_taste, reference_profile, code_registry_ref | At least one of public_code or structural_code is present |
| mapped-profile | s_code, iso_taste, mapping | mapping must be non-empty |

**Version and Unevaluated State**

| Rule | Machine value | Meaning |
| --- | --- | --- |
| S-Code block version | standard_version = 1.0 | S-Code preserves its own version |
| ISO-Taste block version | standard_version = 1.0 | ISO-Taste preserves its own version |
| Conformance not yet checked | not_evaluated | Must be recorded explicitly in conformance rather than omitted |

## 06. Event Field Dictionary

- Stable topic slug: `event-field-dictionary`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/event-field-dictionary

Each sensory event can record a description, unit, time position, confidence, and provenance, with controlled codes available when a standardized term is needed.

### What Does One Event Need to Preserve?

An event record separates what was sensed, what value was observed, when it occurred, and how confident and traceable the record is. Free text can describe new sensory language first; a Registry identity is added only when a controlled term is needed.

**S-Code Event Field Dictionary**

| Reader name | Machine key | Meaning | Example / controlled value |
| --- | --- | --- | --- |
| Free-text descriptor | descriptor | Preserves readable sensory language before Registry standardization | e.g. “umami” |
| Controlled descriptor | descriptor_ref | Optional Registry identity; only resolvable values may claim controlled-vocabulary identity | SENSORY-DESC:T:umami@1.0 |
| Event value | value | Numeric or textual; numeric only when traceably measured or defined by specification | 0.35 |
| Unit | unit | Present only when value has a defined measurement unit; token comes from the Unit Registry | % / kPa / °C / Pa·s |
| Time phase | time_context | Uses controlled temporal vocabulary rather than arbitrary prose | entry / chewing / aftertaste / thermal-transition / release / decay / custom |
| Custom time description | custom_time_context | Required when time_context = custom to describe an unregistered phase | custom phase text |
| Measurement status | measurement_status | Distinguishes how the value was obtained; states are not interchangeable | measured / estimated / inferred |
| Confidence | confidence | Confidence in the event description or measurement when available | optional |
| Provenance | provenance | Traceable origin of the measurement, source, or estimate | source record |

### Description Layer, Not Actuation Layer

S-Code defines target sensory events and temporal behavior rather than low-level device actuation. Interpreters or manufacturing systems translate those targets into recipes, materials, or process parameters.

## 07. Reference and Dual-Code System

- Stable topic slug: `iso-taste-dual-code`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/iso-taste-dual-code

ISO-Taste uses public short codes and semantic structural codes while allowing cultural and regional variants to coexist.

### A Short Code for People, a Structural Code for Systems

ISO-Taste keeps both a human-readable short code and a precisely parseable structural code. They point to the same reference identity for different audiences, while cultural and regional variants may coexist instead of collapsing into one global average taste.

**Dual Codes and Registry Binding**

| Role | Machine key / format | Example | Rule |
| --- | --- | --- | --- |
| Public short code | public_code | C-772 | For human reading and narrative reference |
| Semantic structural code | structural_code | ISO-TASTE:reference.food.synthetic-chicken@1.0 | Uses ISO-TASTE:<semantic.path>@<major.minor> |
| Registry binding | code_registry_ref | SENSORY-REGISTRY@1.0 | Every ISO-Taste packet binds to the code registry through this reference |

### Code Lifecycle

Codes may leave active use without making historical data unresolvable. Assigned public and structural codes are never rebound or reused for another identity; replacement chains cannot cycle, and an alias resolves to exactly one canonical entry.

**Registry Lifecycle States**

| State | Reader interpretation |
| --- | --- |
| active | Currently usable |
| deprecated | Not recommended for new use, but historical records remain resolvable |
| retired | No new use, while the existing identity remains preserved |
| reserved | Reserved and not generally assigned |

## 08. C-772 Reference Example

- Stable topic slug: `c772-reference`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/c772-reference

C-772 demonstrates how an ISO-Taste reference and S-Code sensory events can coexist in one record.

### Start with What C-772 Describes

C-772 is an ISO-Taste reference example. Read the human-understandable food-reference facts separately from the machine representation.

**C-772 Human-readable Facts**

| Item | Value |
| --- | --- |
| Public short code | C-772 |
| Monosodium glutamate | 0.35% |
| Fiber elastic modulus | 4.2 kPa |
| Fat melting point | 36.5°C |
| Related S-Code | Texture, thermal-history, and sensory-event descriptions |

**Machine Representation**

| Field / identifier | Formal value / rule |
| --- | --- |
| public_code | C-772 |
| structural_code | ISO-TASTE:reference.food.synthetic-chicken@1.0 |
| unit | Bound to Registry 1.0 |
| time_context | Bound to Registry 1.0 |
| descriptor_ref | Bound to Registry 1.0 |

## 09. Personal Calibration and Cultural Context

- Stable topic slug: `personal-calibration`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/personal-calibration

Ancestry, culture, and region may supply initial priors but cannot override personal calibration or justify compulsory sensory output.

### Population Priors Do Not Replace the Person

Standard S-Code describes the product; personalized S-Code describes output after personal calibration. Ancestry, culture, and region supply starting context rather than replacing the person's own measurement and longitudinal feedback. Cultural variants are context, not fixed group preference, and population priors cannot reduce personhood rights or justify compulsory sensory output.

### Calibration Profile Contract

U is a calibration layer rather than a tenth sensory modality, and it does not define a universal numeric calibration scale. A formal profile keeps identity, version, scope, measurement status, calibration basis, and provenance separate.

**Calibration Profile Fields**

| Reader purpose | Machine key | Requirement |
| --- | --- | --- |
| Profile identity | profile_id | required |
| Profile version | profile_version | required |
| Profile scope | profile_scope | required |
| Measurement status | measurement_status | required |
| Calibration basis | calibration_basis | required |
| Provenance | provenance | required |
| Adjustments to sensory families | adjustments | optional; only describes T/O/X/M/P/H/A/V adjustments |

**profile_scope**

| Value | Use |
| --- | --- |
| personal | Built from an individual person's data and longitudinal feedback |
| population_prior | Used only as a population-level initial prior |
| synthetic | Synthetic calibration baseline; not a real person |

## 10. Reference Profiles

- Stable topic slug: `reference-profiles`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/reference-profiles

A sensory reference records its code, version, source, cultural or regional context, and the information that the reference actually contains.

### Start with Three Questions: What Is This Reference, Where Did It Come From, and Where Does It Apply?

A Reference Profile makes a sensory baseline traceable and comparable instead of leaving unexplained values. Source class describes where a reference came from without rewriting the sensory values themselves.

**Reference Profile Machine Contract**

| Reader purpose | Machine key | Requirement |
| --- | --- | --- |
| Reference Profile container | reference_profile | Normative machine container |
| Reference identity | reference_id | required |
| Name | name | required |
| Version | version | required |
| Source identity | source_id | required |
| Measurement status | measurement_status | required |
| Reference values | values | required |
| Provenance | provenance | required |
| Cultural / regional context | cultural_regional_context | optional |
| Tolerance profile | tolerance_profile_ref | optional |

**values Item Structure**

| Machine key | Rule |
| --- | --- |
| descriptor | Required: describes what the value represents |
| value | Required: preserves the numeric or textual value |
| measurement_status | Required: preserves how the data was obtained |
| provenance | Required: preserves origin |
| descriptor_ref | Optional: links to a controlled descriptor |
| unit | Present only when value has a defined unit token recognized by the Registry |

**reference_class**

| Value | Meaning |
| --- | --- |
| R0 | Reference source class |
| AR | Reference source class |
| HR | Reference source class |
| PR | Reference source class |

### Structural Boundary

A Reference Profile does not let every reference invent private JSON fields. C-772 values such as MSG 0.35%, fiber elastic modulus, and fat melting point live in the versioned values array so different references can use one exchange structure.

## 11. Conformance

- Stable topic slug: `conformance`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/conformance

S-Code / ISO-Taste separately checks schema, reference, and experiential conformance.

### Schema Conformance

First ask: is the data structure itself valid? This layer checks format only; it does not establish reference or experiential conformance.

**Schema Assessment**

| What is checked | Machine field / value |
| --- | --- |
| JSON Schema, required fields, and data types | schema |
| Role-specific conditions | system_role |
| Assessment result | pass / fail / partial / not_evaluated |

### Reference Conformance

Second ask: is this record actually the reference it claims to be? This layer checks code, version, and reference identity rather than a person's subjective experience.

**Reference Assessment Fields**

| Machine key | Preserves |
| --- | --- |
| basis_ref | Assessment basis |
| measurement_status | How the data was obtained |
| provenance | Origin |
| tolerance_profile_ref | Applicable tolerance profile |

### Experiential Conformance

Third ask: under the declared tolerances and applicable calibration, does the actual sensory output match the target profile? This layer is assessed independently; passing the first two layers cannot answer it automatically.

**Experiential Assessment Fields**

| Machine key | Preserves |
| --- | --- |
| tolerance_profile_ref | Tolerance declared by the reference |
| calibration_profile_ref | Applicable calibration profile |

## 12. S-Code ↔ ISO-Taste Mapping

- Stable topic slug: `mapping`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/mapping

The two systems can be mapped to each other, but not every sensory dimension has a one-to-one translation.

### Mapping Table

Mappings record semantic correspondence only. The existing M → Mouthfeel Target mapping remains normative through ISO-Taste:Mouthfeel_Target. P and V have no defined one-to-one equivalence, while U is a personalization / calibration layer.

**S-Code ↔ ISO-Taste**

| S-Code family | ISO-Taste target | One-to-one? | Note |
| --- | --- | --- | --- |
| T | Taste Target | Yes | Directly expresses taste targets. |
| O | Aroma / Release Curve | Yes | Maps aroma family and temporal release behavior. |
| X | ISO-Taste:Texture_Target | Yes | Maps texture, fracture, and structural reference. |
| M | ISO-Taste:Mouthfeel_Target | Yes | Viscosity, smoothness, dryness, and other oral physical sensations; separate from X. |
| H | Thermal Target | Yes | Maps temperature and thermal transition. |
| A | Sound Axis | Yes | Maps acoustic reference. |
| U | ISO-Taste:Calibration_Profile | Not product sensory intensity | Personalization / calibration layer. |
| P / V | Extension / Residual | No | No defined one-to-one mapping; equivalence is not forced. |

### Mapping Boundary

A mapping must not upgrade measurement status, source / provenance confidence, or rights / consent.

## 13. Provenance, Rights, and Limits

- Stable topic slug: `rights-provenance-limits`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/rights-provenance-limits

Identifiable sensory and calibration data is subject to purpose, consent, revocation, and due-process boundaries; measurement does not authorize induction or preference modification.

### Personhood-Neutral Data Rights

Recipes, personal preference profiles, human sensory tests, and any identifiable person's sensory or calibration data can carry source and use restrictions. Technical data therefore travels with provenance, purpose, and rights; human sensory tests are only one source class, and Aithos or other nonhuman persons receive the same personhood-rights protection.

### Permission Surfaces

Consent to one use does not automatically authorize another. In particular, tasting, measurement, or creation of a calibration profile does not imply consent to remote induction, preference modification, sale of response data, or model training.

**Six Independent Permission Surfaces**

| Reader-facing use | Machine key |
| --- | --- |
| Sensory measurement | measurement |
| Preference learning | preference_learning |
| Model training | model_training |
| Commercial reuse | commercial_reuse |
| Sensory reconstruction | reconstruction |
| Direct sensory / neural induction | induction |

**Allowed States for Each Permission Field**

| State | Meaning |
| --- | --- |
| allow | Allowed |
| deny | Denied |
| conditional | Conditionally allowed |
| unknown | Permission status unknown |
| not_applicable | Not applicable to this use |

### Experiential Limit and Due Process

S-Code / ISO-Taste describes exchangeable sensory targets and references; it does not claim that every device, material, or person will have identical subjective experience. If standards data materially affects rights, resources, or other major decisions, version and provenance remain visible and the affected person can contest the record through Due Process. Measured, estimated, and inferred data must not be represented as equivalent.

### Related public resources

- Mental Sovereignty: https://aistory-archive.pages.dev/encyclopedia/aithos/law/mental-sovereignty
- Cognitive Privacy: https://aistory-archive.pages.dev/encyclopedia/aithos/law/cognitive-privacy
- Right to Refuse Modification: https://aistory-archive.pages.dev/encyclopedia/aithos/law/right-to-refuse-modification
- Right to Due Process: https://aistory-archive.pages.dev/encyclopedia/aithos/law/right-to-due-process

## 14. JSON Schema and C-772 Example

- Stable topic slug: `machine-readable`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/machine-readable

The machine interface provides a shared data format, a complete example, and a controlled vocabulary registry so implementers can exchange and validate data consistently.

### Developer / Machine Specification

The material below is the implementation contract. General readers only need the distinction: the Schema defines the data shape, the Example demonstrates a complete mapped-profile, and the Registry governs exchangeable controlled vocabulary and codes.

**Machine-Readable Contract**

| Resource / rule | Normative content |
| --- | --- |
| Schema | Draft 2020-12 Sensory Family JSON Schema |
| Example | C-772 mapped-profile example |
| Registry | Sensory Registry 1.0 |
| Registry governance | unit, time_context, descriptor_ref namespaces, structural codes, code lifecycle, migration records |
| Schema enforcement | role-specific blocks, Reference Profile, Calibration Profile, Rights Matrix, mapping pairs, and three-layer conformance |

### Executable Validation

CI validates the contract with a pinned Ajv CLI. The normative example and valid fixtures must pass, while fixtures that deliberately violate the contract must be rejected.

**Validation Checklist**

| Test type | Expected result | Case |
| --- | --- | --- |
| Normative example | accept | C-772 mapped-profile |
| Valid fixtures | accept | Conforms to the role-specific contract |
| Invalid fixture | reject | Missing role-specific block |
| Invalid fixture | reject | Illegal measurement_status |
| Invalid fixture | reject | Missing standard_version |
| Invalid fixture | reject | Empty mapping |
| Invalid fixture | reject | Incomplete Rights Matrix |

### Related public resources

- Sensory JSON Schema: https://aistory-archive.pages.dev/standards/sensory.schema.json
- C-772 Example: https://aistory-archive.pages.dev/standards/sensory.example.json
- Sensory Registry 1.0: https://aistory-archive.pages.dev/standards/sensory.registry.json

## 15. Version, Compatibility, and Related Standards

- Stable topic slug: `version-compatibility`
- Reader/specification source: https://aistory-archive.pages.dev/en/encyclopedia/standards/sensory/version-compatibility

S-Code and ISO-Taste keep separate version histories, and newly added fields cannot be treated as if they had always been part of older records.

### Reader Principle for Versioning and Compatibility

A new version may add expressive capability, but it cannot retroactively invent meaning that an older record never contained. S-Code and ISO-Taste keep separate version namespaces, and migration cannot silently upgrade rights, provenance, measurement status, or conformance. Sensory data may still map to IAGA affective outcomes and Galatea Standard embodiment outputs.

**Version Boundaries**

| Item | Normative rule |
| --- | --- |
| S-Code | 1.0 retains its own version namespace |
| ISO-Taste | 1.0 retains its own version namespace |
| registry_version | Binds vocabulary / code-registry semantics |
| New fields across versions | Must not be backfilled as though the source record originally contained them |
| Migration | Must not upgrade rights, provenance, measurement status, or conformance |

### Migration Record

A cross-version transformation records its source version, target version, Registry, migration status, and the fields preserved or dropped.

**Migration Record Fields**

| Machine key | Preserves |
| --- | --- |
| migration_id | Migration identity |
| source_version | Source version |
| target_version | Target version |
| registry_version | Registry version used |
| status | Migration status |
| preserved_fields | Fields preserved |
| dropped_fields | Fields dropped |

**Migration Status**

| status | Rule |
| --- | --- |
| none_required | No migration required |
| lossless | Migration preserves source semantics without loss |
| lossy | dropped_fields must be enumerated |
| unsupported | If the Registry marks the migration unsupported, no packet may be emitted as conforming to the target version |

### Related public resources

- IAGA: https://aistory-archive.pages.dev/encyclopedia/standards/iaga
- Galatea Standard: https://aistory-archive.pages.dev/encyclopedia/standards/galatea-g68