Skip to main content
IronKernel
Products Solutions For Customers About FAQ Contact
IronKernel Platform

Shared runtime primitives

Routing and geofence capabilities are implemented as shared libraries consumed across operational products.

Operating problem

Platform reliability drops when each product reimplements core routing and geofence logic independently.

Pillar commitments

  • Routing provider abstraction supports multiple backends.
  • Geofence engine centralizes zone logic and event semantics.
  • Products consume shared primitives rather than duplicate implementations.

How this pillar operates

These steps describe how the platform principle is applied through implementation and route-level verification.

  1. Step 1

    Centralize primitives in shared libs

    Routing and geofence behavior is maintained once in platform libraries.

  2. Step 2

    Consume primitives in product workflows

    Execution modules call shared primitives instead of bespoke implementations.

  3. Step 3

    Validate behavior through operations pages

    Operational routes expose how shared primitives affect dispatch and yard outcomes.

Validation checklist

  • Routing behavior remains consistent across product workflows.
  • Geofence-driven state transitions are defined once and reused.
  • Operational pages reference shared library evidence for claims.

Proof model

Platform-level proof

  • Routing provider module is documented and implemented as shared platform capability.

    verified

    docs/products/ironkernel/product.md · Module Catalog > Routing Provider

    Code: backend/libs/routing

  • Geofence engine module is documented and implemented for cross-product use.

    verified

    docs/products/ironkernel/product.md · Module Catalog > Geofence Engine

    Code: backend/libs/geofence