Sense 53 — The Codex

Sense 53 · In bloom · Last touched 2026-08-23

• last_verified: 2026-07-27

Synced from docs/design/sense_53_the_codex.md in the engine repo — that’s the source; this page is a build-time mirror.

Status: proposal · 2026-07-09 Author: claude (Opus 4.7) with Mig Sense number: 53 (verified free on origin/main; Sense 52 The Cartography claimed the previous slot)

The one-line pitch

Industry-recognised standards live in the platform, not in packs or tenants. jinflow declares which standards it speaks, exposes them uniformly, and lets packs opt in by reference.

Standards are business-independent — an ISO code means the same thing in a hospital, a vineyard, a freight forwarder, and a freshwater sensor network. Baking them into a pack duplicates the work, hides them from the customer, and makes upgrading the standard a per-pack chore. Naming them, hosting them once in the engine, and exposing them makes jinflow’s technical trustworthiness legible.

Why now

We already do this. We just never named it.

Sense 14.2 Phase 5 shipped with three ISO standards + UCUM baked into the engine:

• scripts/ucum.py — Unified Code for Units of Measure. Validates every quantity aggregate.
• ISO 4217 currency codes — validates every currency aggregate.
• ISO 8601 durations — validates every window: declaration on time-scoped signals.
• ISO 80000 quantity kinds — referenced in [[project_unit_standards_architecture]] as the theoretical basis for the unit hierarchy.

Every pack that adopted Phase 5 (numetrix, hrcentral, alptrack, millesime, lexflow, interlogic, riverflow) got these standards for free. Nobody in a pack had to think about them. The pattern was there; it just didn’t have a home.

Then on 2026-07-09, Mig proposed adding OGC SensorThings API to riverflow (and later WaterML 2, USGS parameter codes, BAFU conventions). Instead of tucking them into packs/riverflow/, he asked the sharper question: “why don’t standards belong to the platform?” — and answered it: because they’re business-independent, they always have.

This spec formalises the pattern.

The three questions the reader wants

Mirroring Sense 15’s CEO conversation and Sense 52’s field-team dance:

1. “Which standards?” — the customer asks “does jinflow speak my industry’s data conventions?” Answer: a discoverable list, at every reader’s fingertips.
2. “Where do they live?” — the engineer asks “do I have to implement UCUM in my pack, or is it already there?” Answer: platform-hosted, opt in by reference.
3. “How do I know they’re real?” — the reviewer asks “is this a marketing claim or an implementation?” Answer: each standard YAML declares its jinflow_conformance block — which entity types honor it, which features are covered, testing status, gaps.

Any registry that answers only one of the three is a marketing page. A registry that answers all three is a Codex.

The layer boundary

The Sense 43 cascade + [[feedback_config_cascade_is_not_layered_pack_tenant]] established the three layers:

┌──────────────────────────────────────────────────┐
│  Engine (platform)                               │
│    ├── Sense definitions                         │
│    ├── Compilers, validators, JinDesk           │
│    └── Standards ← Sense 53 declares this        │
├──────────────────────────────────────────────────┤
│  Domain pack                                     │
│    ├── Signals, theses, verdicts                 │
│    ├── Subject Matter                            │
│    └── standards: [ucum, iso_8601, sensorthings] │
├──────────────────────────────────────────────────┤
│  Tenant                                          │
│    ├── Everything the tenant instantiates        │
│    └── Inherits pack's standards declarations    │
└──────────────────────────────────────────────────┘

Standards flow strictly downward. A pack adopts platform standards; a tenant inherits pack standards. A tenant may not invent its own standards. A pack may not ship its own “standard” (it’s a pack convention at that point, not a standard). The Codex is engine-only.

Why enforce this? Because a “standard” is only a standard if the vocabulary is external, stable, and shared. The moment a pack invents a “standard” for itself, it stops being a standard and becomes a private schema. That distinction is what makes the answer to “does jinflow speak SensorThings?” meaningful — it’s yes for every pack that opts in, not “well, depends which pack you’re using.”

Standards YAML declarations

Live in engine/standards/*.yaml (a new directory in the engine repo). Each standard declares itself:

standard_id: ogc_sensorthings_1_1
kind: standard                     # required — first-class type
version: '1.0'                     # of this DECLARATION (our spec of it), not of the standard
adopted_at: 2026-07-13             # date the platform first honored this
modified_at: 2026-07-13

# The standard's own identity
full_name:
  en: OGC SensorThings API
  de: OGC SensorThings API
  fr: API SensorThings de l'OGC
  it: API SensorThings dell'OGC

family: OGC                        # ISO / OGC / IETF / W3C / national / trade body / de facto
standard_version: '1.1'            # of the underlying spec (v1.1 of SensorThings itself)
published_by: Open Geospatial Consortium
first_published: 2016
current_edition: 2021-05

jurisdiction: [global]             # global | eu | ch | us | ... — where this standard governs

# The description customer readers see
description:
  en: |
    A REST-like OGC standard for the exchange of Internet-of-Things
    sensor data. Defines a data model (Thing, Sensor, ObservedProperty,
    Datastream, Observation, FeatureOfInterest, Location) and a
    JSON-LD API for querying it. Widely adopted by environmental
    monitoring networks, smart-city platforms, and federated sensor
    registries.
  de: |
    Ein REST-artiger OGC-Standard für den Austausch von IoT-Sensor-
    daten. Definiert ein Datenmodell (Thing, Sensor, ObservedProperty,
    Datastream, Observation, FeatureOfInterest, Location) und eine
    JSON-LD-API zu dessen Abfrage. Weit verbreitet bei
    Umweltmonitoring-Netzwerken, Smart-City-Plattformen und
    föderierten Sensor-Registern.
  # ... fr, it (kept concise in this example)

# Where readers can go for the canonical spec
references:
  - label: Canonical specification
    url: https://www.ogc.org/standards/sensorthings/
  - label: Data model overview
    url: https://docs.ogc.org/is/18-088/18-088.html
  - label: Reference implementation (FROST-Server)
    url: https://www.iosb.fraunhofer.de/en/projects-and-products/frost-server.html

# Conformance — the honest answer to "how much of this do you actually implement?"
jinflow_conformance:
  status: partial              # partial | full | planned | deprecated
  first_release: 0.56.0        # version this landed in

  # Which of our entity types map to standard concepts
  entity_mapping:
    - standard_concept: Thing
      jinflow_entity: DeploymentSite
    - standard_concept: Sensor
      jinflow_entity: Sensor
    - standard_concept: Datastream
      jinflow_entity: Datastream
    - standard_concept: Observation
      jinflow_entity: Reading         # deliberate: we keep our word to avoid the Sense 15 clash
      naming_note: |
        SensorThings uses "Observation" for the atomic data point. We
        preserve "Reading" in all our user-facing surfaces because
        Sense 15 "Observation" already means a signed strategic claim.
        The vocabularies map bidirectionally in the JSON-LD export.
    - standard_concept: FeatureOfInterest
      jinflow_entity: Reach

  # What we implement
  features_supported:
    - Data model conformance for Thing, Sensor, ObservedProperty, Datastream, Observation, FeatureOfInterest
    - JSON-LD REST endpoints (read-only)
    - $expand, $filter, $orderby query options
    - MQTT push (planned for a future release)

  # What we don't (yet)
  features_not_covered:
    - Write endpoints (create/update Observations via HTTP POST)
    - MultiDatastream (multi-observation composites)
    - Task and Actuation extensions
    - Full historical location tracking

  # Which packs currently use it
  adopting_packs:
    - riverflow

  # Anchor to where this is implemented + tested
  implementation_pointers:
    - path: explorer/src/routes/[tenant]/sensorthings/
      what: JSON-LD API routes
    - path: packs/riverflow/entities/datastreams.yaml
      what: Datastream entity contract
    - path: tests/test_sensorthings_conformance.py
      what: Conformance test suite

# Related standards worth cross-referencing
related_standards:
  - ogc_sensorml
  - ogc_waterml_2_0
  - usgs_parameter_codes

# Any known deprecation or successor
successor: null
deprecated_at: null

tags: [sensor_data, iot, environmental_monitoring, time_series, ogc]

Notes on the shape:

• Bilingual by default — description in all four JinDesk locales (EN/DE/FR/IT). Standards are customer-facing prose.
• Honest jinflow_conformance — the coverage block is the “how do I know it’s real” answer. Every claim about a standard should be pointer-verifiable to a file path.
• Entity mapping is explicit — makes vocabulary clashes surface early (like our Sense 15 Observation ↔ SensorThings Observation issue).
• References are external — the canonical spec always lives outside jinflow. We describe our conformance, not the standard itself.

Registry compilation

New engine machinery mirroring existing compilers:

• scripts/standardcheck.py — validates each engine/standards/*.yaml against a contract (engine/contracts/standard_contract.v1.json). Ensures required fields present, references URL-shaped, family in the allowed enum, no duplicate standard_id.
• scripts/standardcompile.py — compiles all standards into a single SQL registry engine.standard_registry baked into every KLS (yes, every KLS carries the codex — costs almost nothing, gains discoverability).
• Alternative for V1: the standards registry is a build-time JSON asset shipped alongside JinDesk, no per-KLS baking. Simpler start. Trade-off: standards visible only in JinDesk, not queryable from dbt. V1 recommendation: build-time JSON asset.

Pack adoption pattern

Packs declare adopted standards in their pack manifest:

# packs/riverflow/pack.yaml (or wherever the manifest lives)
pack_id: riverflow
standards:
  - id: ucum
    scope: quantities
  - id: iso_4217
    scope: none                    # no currency in riverflow
    reason: declared_for_consistency_not_used
  - id: iso_8601
    scope: durations_and_timestamps
  - id: ogc_sensorthings_1_1
    scope: gold_datastreams + gold_readings + sensorthings_api
  - id: ogc_waterml_2_0
    scope: planned                 # V2
  - id: usgs_parameter_codes
    scope: observed_properties

What this unlocks:

• JinDesk /what-is-this shows per-pack: “This pack speaks UCUM, ISO 8601, and OGC SensorThings API v1.1.”
• Validators can check that a pack claiming SensorThings conformance actually implements the Datastream entity.
• jinflow doctor <pack> (future verb) can audit conformance drift.
• Customer conversations get a concrete answer instead of hand-waving.

And column-level bindings live in the Typology ([[sense_54_the_typology]]). The pack manifest above declares “this pack adopts UCUM”; the Typology declares “this column binds to UCUM as a quantity.” The Codex adds a binding_kinds field to each standard’s YAML (which of the eight Typology kinds this standard is legitimate to bind to — usually one, sometimes multiple, sometimes empty for structural standards like OGC SensorThings that describe entity shapes rather than column-level types) so the Typology checker can refuse illegal pairings at compile time. The Typology compile writes state/typology_coverage.json — a build artifact, not a database view — and the Codex reader consumes it for a real answer to “what fraction of this pack’s columns are assayed against which standards?”. The two Senses cooperate through file and schema, not through a shared database surface; the KLS never sees types because types are declarations, not runtime data.

The pack-builder journey

Standards are only useful if a pack builder can find them, understand them, adopt them, and prove conformance. The four moves:

1. Discovery — “What standards does jinflow support?”

Three parallel surfaces, all reading from the same source (engine/standards/*.yaml):

Surface	Audience	Purpose
CLI jinflow standards ls	Builder at terminal	One-line entries with id / family / status / adopting packs
Docs site docs.jinflow.io/standards/	Builder reading async	Full auto-generated reference pages, one per standard
JinDesk /what-is-this/standards	Customer + builder browsing	Same content, embedded in tenant JinDesk

Any standard added → next docs build → all three surfaces update. No parallel maintenance ever.

2. Reference — “What does the standard actually say?”

The Codex does not duplicate specifications. OGC is the source of truth for what SensorThings is. We describe what we implement of it. Every standard YAML’s references: block carries the canonical external links:

references:
  - label: Canonical specification
    url: https://www.ogc.org/standards/sensorthings/
  - label: Data model overview
    url: https://docs.ogc.org/is/18-088/18-088.html
  - label: Reference implementation (FROST-Server)
    url: https://www.iosb.fraunhofer.de/en/projects-and-products/frost-server.html

The detail page renders our conformance notes + a “Learn the standard itself” section with these external links. Builders needing the actual spec text click out. Builders needing to know what jinflow implements stay in.

3. How-to — “How do I actually use this in my pack?”

Each non-trivial standard has a dedicated cookbook recipe. The cookbook is the how-to layer:

• docs.jinflow.io/cookbook/adopting-sensorthings/ — step-by-step for a pack builder:
  1. Declare standards: [ogc_sensorthings_1_1] in your pack manifest
  2. Add Datastream + ObservedProperty to your Gold contract (shows the YAML)
  3. Look at the reference implementation: packs/riverflow/entities/datastreams.yaml — copy this pattern
  4. What your signals look like after adoption (before/after side-by-side)
  5. How the JSON-LD export lights up automatically
• docs.jinflow.io/cookbook/using-ucum-units/ — for the simpler standards
• docs.jinflow.io/cookbook/expressing-iso-8601-durations/

Reference implementations are teaching material. The implementation_pointers block in the standard declaration lists every artifact a builder can copy from — an entity YAML, a route implementation, a test suite. Every path in that block is a live file, not a placeholder. When we say “learn from riverflow’s Datastream,” we mean literally open the file.

4. Validation — “Is my pack actually conformant?”

Three enforcement layers, each with its own tool:

Layer	Tool	Checks
Standard itself	jinflow standardcheck	Standard YAMLs valid against standard_contract.v1.json
Pack claims	jinflow packcheck <pack> (future verb)	Pack claiming a standard has the required entities + fields
Runtime conformance	Test suite — e.g. tests/test_sensorthings_conformance.py	JSON-LD endpoints pass the OGC compliance harness

If runtime conformance fails, the standard’s status downgrades in the Codex — no marketing claim outlives a failing test.

Concrete example: a builder adopts SensorThings

# Discovery
$ jinflow standards ls
  ucum                    de facto   Full        Since 0.55.0
  iso_4217                ISO        Full        Since 0.55.5
  iso_8601                ISO        Full        Since 0.55.2
  iso_80000               ISO        Referenced
  ogc_sensorthings_1_1    OGC        Partial     Since 0.56.0  (riverflow)

$ jinflow standards show ogc_sensorthings_1_1
  [renders the detail: family, status, entity mapping, features,
   references, adopting packs, implementation pointers]

# Read the cookbook
$ open https://docs.jinflow.io/cookbook/adopting-sensorthings/

# Read the reference implementation
$ open ~/Programming/jazzisnow/jinflow-packhub/jinflow-pack-riverflow/entities/datastreams.yaml

# Adopt in your pack
$ vim packs/my-pack/pack.yaml         # add standards: [ogc_sensorthings_1_1]
$ vim packs/my-pack/entities/*.yaml   # add Datastream + ObservedProperty

# Validate
$ jinflow packcheck my-pack
  ✓ Pack claims OGC SensorThings v1.1
  ✓ Datastream entity present
  ✓ ObservedProperty entity present
  ✓ Standard conformance markers present in Gold contract
  ⚠ No integration test for JSON-LD endpoint — recommended

Zero surprise. Every step has a resource pointing at the next step. The pack builder never has to reverse-engineer what jinflow supports — they just ask jinflow standards.

Future — IDE / editor completion

Not V1, but the same YAML source enables:

• LSP-style autocomplete for unit: fields (suggests valid UCUM codes)
• LSP-style autocomplete for currency: fields (suggests ISO 4217 codes)
• Inline validation warnings for typos (unit: kilogramm → red-underline, “Did you mean kg?”)
• Standards manifest as a schema companion — editors that understand JSON Schema can validate pack YAMLs against declared standards at edit-time

The lift from CLI-based validation to editor-time validation is one JSON Schema export away. Deferred to V2.

JinDesk surface: the /what-is-this Standards tab

The /what-is-this page already exists as the customer-facing introduction. Adding a Standards tab as a first-class navigation item:

List view — /what-is-this/standards

[Search / filter by family: ISO · OGC · IETF · national · trade body]

┌─────────────────────────────────────────────────────────────┐
│ UCUM — Unified Code for Units of Measure           [Full]   │
│ Family: de facto · Adopted 2026-05-08                       │
│ Validates every quantity aggregate in the engine.           │
├─────────────────────────────────────────────────────────────┤
│ ISO 4217 — Currency Codes                          [Full]   │
│ Family: ISO · Adopted 2026-05-27                            │
│ Validates every currency aggregate. Alignment: 100%.        │
├─────────────────────────────────────────────────────────────┤
│ ISO 8601 — Durations & Timestamps                  [Full]   │
│ Family: ISO · Adopted 2026-05-22                            │
│ Validates window: declarations on time-scoped signals.      │
├─────────────────────────────────────────────────────────────┤
│ OGC SensorThings API v1.1                          [Partial]│
│ Family: OGC · Adopted 2026-07-13                            │
│ Data model + JSON-LD read API. Adopted by: riverflow.       │
└─────────────────────────────────────────────────────────────┘

Detail view — /what-is-this/standards/ogc_sensorthings_1_1

Renders the full standard YAML: description (multilingual), family, jurisdiction, references (external links), conformance status, entity mappings, supported features, gaps, adopting packs, implementation pointers.

Why on /what-is-this? — because that’s the audience. Customers, prospects, integration partners. Not analysts. The Codex is the “here’s what we speak” tab, next to “here’s what we do” and “here’s who we are.”

Documentation generation

One YAML source drives every surface — CLI, docs site, JinDesk. The three renderers differ; the truth is single.

                    ┌─────────────────────────────┐
                    │  engine/standards/*.yaml    │
                    │  (single source of truth)   │
                    └──────────────┬──────────────┘
                                   │
              ┌────────────────────┼────────────────────┐
              │                    │                    │
              ▼                    ▼                    ▼
   ┌─────────────────┐   ┌───────────────────┐   ┌──────────────────────┐
   │ CLI verb        │   │ Docs site         │   │ JinDesk tab         │
   │ jinflow         │   │ Starlight         │   │ /what-is-this/       │
   │ standards ls    │   │ collection        │   │ standards            │
   │ jinflow         │   │ auto-built at     │   │ Read from bundled    │
   │ standards show  │   │ docs deploy       │   │ JSON asset at boot   │
   └─────────────────┘   └───────────────────┘   └──────────────────────┘

Build-time asset generation

At engine release time:

1. scripts/standardcompile.py reads every engine/standards/*.yaml
2. Validates each against engine/contracts/standard_contract.v1.json
3. Emits three artifacts, all from the same run:
   • dist/standards/registry.json — bundled with JinDesk, read at boot for the /what-is-this/standards tab
   • site/src/content/docs/standards/{standard_id}.md — Starlight collection entries, auto-generated with rich frontmatter (title, family, adopted date, tags), auto-linked from the sidebar
   • scripts/systemdb.py populates a standards table in the system DB for the CLI to read

Zero parallel maintenance. A standard’s description is written once in the YAML; the CLI shows it, the docs site renders it, JinDesk displays it. Adding a translation, updating a reference URL, correcting a conformance status — one edit, all three surfaces catch up on next build.

Docs site sidebar

The Starlight collection auto-links standards into the site nav under a Standards section:

Docs
├─ Get started
├─ Concepts
├─ Reference
│   ├─ CLI
│   ├─ Contracts
│   └─ Standards
│       ├─ Overview (index page)
│       ├─ ISO 4217 — Currency Codes
│       ├─ ISO 8601 — Durations & Timestamps
│       ├─ ISO 80000 — Quantity Kinds
│       ├─ OGC SensorThings API v1.1
│       └─ UCUM — Unified Code for Units of Measure
├─ Cookbook
│   ├─ Adopting SensorThings
│   ├─ Using UCUM units
│   └─ ...
└─ Senses

Cookbook recipes live under Cookbook, not under Standards — they’re how-tos, not references. The standard’s detail page carries a “See cookbook: Adopting SensorThings” link.

CLI grammar

jinflow standards ls                          # list all
jinflow standards ls --family ISO             # filter by family
jinflow standards ls --status Full            # filter by conformance
jinflow standards show <standard_id>          # detail view
jinflow standards show <standard_id> --json   # machine-readable

Follows the same grammar as jinflow signals, jinflow theses, jinflow packs — one verb per artifact type, ls + show + optional filters. Mimicry keeps the muscle memory intact.

Auditability of the source YAML

Every standard YAML lives in engine/standards/ in the engine git repo. That means:

• Changes are reviewable. A PR that adds SensorML gets read like any other engine change.
• History is traceable. git blame engine/standards/ogc_sensorthings_1_1.yaml shows who added which conformance claim when.
• CI runs standardcheck on every commit — no standard ships broken.

Extensibility roadmap

Mig’s question — “not sure whether this will be able to be extensible without restart or redeployment. We will see about this.” — deserves a concrete answer per phase.

V1 — Bundled with engine (ship 0.56.0)

• All standards live in engine/standards/*.yaml in the engine repo
• Adding a standard = engine PR + release
• Simple, auditable, secure. Same trust model as scripts/ucum.py today.
• Trade-off: adding SensorML requires an engine ship. Realistic; standards don’t change often.

V2 — External manifest URL (ship 0.6X)

• Engine config carries codex_manifest_url: https://standards.jinflow.io/registry.json
• At JinDesk boot, engine fetches manifest, validates signature, hot-loads into runtime registry
• Adding a standard = update the manifest URL. No engine ship.
• Signed manifests (Ed25519 or similar) prevent tampering.
• Cache locally; degrade gracefully if URL unreachable (fall back to bundled snapshot).
• Trade-off: adds a network dependency at boot.

V3 — Federated standards commons (aspirational)

• Multiple bodies each publish their own registries: standards.ogc.org/registry.json, standards.iso.org/registry.json, standards.iana.org/registry.json
• jinflow federates from all of them
• Trust anchored in cryptographic signatures from each body
• Requires industry buy-in beyond jinflow’s remit; more of a “wouldn’t it be cool” than a plan

Realistic recommendation: ship V1 now, plan V2 for when we have 12+ standards, treat V3 as inspiration only.

V1 bundled standards (Phase 1 shipping list)

Retroactively formalising what already exists + one new:

Standard	Family	Already implemented?
UCUM	de facto	✅ scripts/ucum.py since 2026-05-08 (Sense 14.2 P0)
ISO 4217	ISO	✅ Sense 14.2 Phase 3 currency machinery
ISO 8601	ISO	✅ Duration validators in signalcheck
ISO 80000	ISO	✅ Referenced in unit hierarchy — declaration formalises
OGC SensorThings API v1.1	OGC	⏳ landing 0.56.0 (Phase 2 of this Sense)

Four are retroactive naming; one is new. Every existing test that references UCUM/ISO 4217/ISO 8601 becomes de-facto conformance evidence, pointer-linked from the standard’s implementation_pointers.

Phase 2 — first NEW standard: OGC SensorThings API

The riverflow SensorThings adoption becomes the first new standard added via the Codex rather than a pack-specific implementation. Same code, better home.

Concrete shape:

1. engine/standards/ogc_sensorthings_1_1.yaml — the standard declaration (per the annotated example above).
2. engine/standards/usgs_parameter_codes.yaml — companion standard (a Datastream’s ObservedProperty is identified by a USGS code).
3. engine/standards/ogc_waterml_2_0.yaml — declared as status: planned for now, actual implementation later.
4. packs/riverflow/pack.yaml declares standards: [ucum, iso_8601, ogc_sensorthings_1_1, usgs_parameter_codes].
5. packs/riverflow/entities/datastreams.yaml — new entity Datastream in the Gold contract. Aligned with SensorThings.
6. packs/riverflow/entities/observed_properties.yaml — new entity ObservedProperty, seeded from USGS codes.
7. Riverflow gold_readings reshaped from wide to long: (reading_id, datastream_id, timestamp, value). Silver stays wide (source-system-shaped).
8. JinDesk routes /{tenant}/sensorthings/v1.1/... emit standards-compliant JSON-LD.

The vocabulary decision made in yesterday’s chat holds: riverflow keeps the word “Reading” in every user-facing surface; the JSON-LD API emits “Observation” only in export. The standard declaration documents the mapping explicitly.

Sense-worthiness

Yes. This deserves canon.

• Structural: it establishes a boundary (standards ≠ packs) that changes how everyone thinks about pack development.
• Retroactive: it names a pattern already in the engine (UCUM, ISO 4217, ISO 8601) without changing behavior.
• Extensible: opens the door to any future standard (FHIR, ICD-10, GDPR audit conformance, WCAG, ISO 27001) via one uniform declaration mechanism.
• Customer-facing: gives sales, integration partners, and reviewers a concrete answer.

Cross-references

• [[project_sense_14_2_phase5_shipped]] — the retroactive predecessor. Everything UCUM/ISO Phase 5 shipped becomes the first four Codex entries.
• [[project_unit_standards_architecture]] — three-level unit architecture: engine (UCUM) / pack (contextual units) / tenant (definitions). Codex formalises the engine layer of this.
• [[project_sense_43_the_cascade]] — same shape at a different level. Cascade cascades config; Codex hosts standards. Both are engine-owned.
• [[feedback_config_cascade_is_not_layered_pack_tenant]] — reinforces the boundary. Tenants fork packs; packs adopt standards.
• [[project_sense_15]] — vocabulary clash: SensorThings “Observation” ≠ Sense 15 “Observation.” The Codex declaration is where this mapping is documented and enforced.
• Sense 52 The Cartography — Cartography’s layers will reference ObservedProperties and Datastreams (once landed). Codex → SensorThings → Cartography is a clean dependency chain.

What we’re NOT doing

• Not becoming a standards body. We describe our conformance to external standards. We don’t define new standards.
• Not maintaining every version of every standard. One standard_version per declaration; superseded editions get a deprecated_at and a successor: pointer.
• Not enforcing conformance at build time in V1. Packs declare adopted standards; enforcement (is this pack's implementation actually SensorThings-conformant?) is planned for V2 via jinflow doctor <pack>.
• Not localising the standard itself. Only the description is quadrilingual. The standard’s canonical text stays in whatever language the body publishes it (English for OGC, French for AFNOR, etc.).
• Not licensing standards. OGC publishes SensorThings openly; ISO charges for full spec access. We link to canonical sources; users buy licenses if their org requires the full text.

Open questions

1. Where does the manifest URL for V2 point? — standards.jinflow.io? Own subdomain, own signing key? Or reuse an existing CDN? Not V1-blocking.
2. Do tenants see per-tenant conformance status? — “your tenant uses SensorThings via the riverflow pack; you’re covered.” Simple derivation; nice touch on the /about page.
3. Ronnie’s read — Codex names something adjacent to Sense 14.2 (her territory in unit architecture). Should confirm alignment before implementation.
4. Standards as Sense 15 anchor kind? — probably yes. {kind: standard, id: ogc_sensorthings_1_1} is a valid anchor for observations about compliance. Add to anchorRoute.ts when Codex ships.
5. Should the Codex ship in the tenant KLS or only in JinDesk’s assets? — arguments both ways. V1: JinDesk-only. Reconsider when a signal/thesis wants to reference a standard.

Signature

Proposed 2026-07-09 by claude (Opus 4.7) with Mig, after Mig’s insight that standards belong to the platform layer. Awaiting Mig’s ratification and Ronnie’s read (Sense 14.2 alignment). No solo structural moves per [[feedback_team_no_solo_structural_moves]] — proposal-then-execute.

---

Numerical neighbors: ← Sense 52 — The Cartography · Sense 54 — The Typology →