oee-chain

Overview ¶

Package oee-chain demonstrates the three-layer go-codex architecture end-to-end:

Layer 1: codex — validated domain types + codex.MapCodecSafe for wire-type bridging
Layer 2: api/events — channel contracts, AsyncAPI spec generation
Layer 3: forge — named, governed KPI computation with pipeline spec generation

Use case: OT sensors publish equipment measurements as raw JSON over MQTT. Our service consumes those messages, validates the payload, maps float64 wire values to strongly typed domain values, and computes OEE (Overall Equipment Efficiency) KPIs through a governed forge pipeline.

Pipeline overview:

Sensor JSON  ──decode──▶  SensorReading (codex.MapCodecSafe maps float64 → domain types)
                                 │
                      ┌──────────┼──────────┐
                      ▼          ▼           ▼
             availabilityCalc  performanceCalc  qualityCalc
             (forge.Function)  (forge.Function) (forge.Function)
                      │          │           │
                      └──────────┴──────────┘
                                 │
                            oeeCalc.Apply
                            (forge.Function)
                                 │
                           KPIResult ──publish──▶ broker

Why codex.MapCodecSafe for wire bridging, not forge.Function?

codex.MapCodecSafe answers: "How do I represent float64 as PlannedTime?"
  ✓ Bidirectional (encode + decode)   ✓ Structural/representational concern
  ✗ No name/version/governance        ✗ Not tracked in pipeline spec

forge.Function answers: "What governed computation derives Availability from AvailabilityIn?"
  ✓ Named + versioned + SHA-256 hash  ✓ Registry → pipeline YAML spec
  ✓ PipelineObserver telemetry         ✓ Governance metadata (author, approvals)
  ✗ Unidirectional only               ✗ Not for structural type mapping

Run with: go run ./examples/oee-chain