cloud-itonami-isic-4921

Open Business Blueprint for ISIC Rev.5 4921: urban and suburban passenger land transport -- city bus, tram, light rail, and taxi/ rideshare dispatch coordination.

This repository publishes an urban/suburban-passenger-transit SCHEDULING/DISPATCH LOGISTICS COORDINATION actor -- trip/ridership/ incident-report data logging, vehicle/route/timetable dispatch scheduling, fleet maintenance procurement coordination, and vehicle- defect/driver-fitness/route-hazard concern flagging -- as an OSS business that any qualified transit operator can fork, deploy, run, improve and sell, so an independent urban/suburban transit operator never surrenders its dispatch-operations data to a closed back-office SaaS.

Built on this workspace's langgraph StateGraph runtime (portable .cljc, supervised superstep loop, interrupts, in-mem/Datomic checkpoints) -- the same actor pattern as every prior actor in this fleet -- here it is TransitDispatchAdvisor ⊣ UrbanTransitDispatchGovernor. This blueprint's own :itonami.blueprint/governor keyword, :urban-transit-dispatch-governor, is a distinct, independent build (no naming-collision precedent question -- confirmed distinct from sibling ISIC 4911's own :rail-safety-governor and every other governor keyword registered across the cloud-itonami org).

Why an actor layer at all? An LLM is great at drafting a service- record summary, a dispatch-scheduling proposal, or a maintenance- order request -- but it has no license to actually finalize a dispatch-safety-clearance decision or determine a driver's fitness to drive, no way to independently confirm a route, a vehicle or an operator is actually a registered/verified party, and no notion of when a "flag this concern" op quietly turns into a claim to have already acted on it. Letting it act directly invites an unverified route entering the ledger, an unregistered vehicle or an unlicensed driver being scheduled into revenue passenger service, or -- worst of all -- a fabricated claim to have cleared a vehicle for departure despite a reported defect, putting passengers at real risk. This project seals the TransitDispatchAdvisor into a single node and wraps it with an independent UrbanTransitDispatchGovernor, a human approval workflow, and an immutable audit ledger.

Scope: coordination only, never vehicle operation or safety-clearance authority

This actor is scheduling/dispatch logistics coordination only. It never performs or authorizes:

• directly operating a vehicle
• overriding a driver's or dispatcher's safety judgment
• directly finalizing a dispatch-safety-clearance decision
• determining driver fitness-to-drive

The governor's scope-exclusion-violations check re-scans every proposal for this failure mode independently of the advisor's own framing, and treats it as a HARD, permanent block regardless of confidence or how clean everything else is. Flagging a vehicle-defect/ driver-fitness/route-hazard concern for a human to triage is exactly this actor's job -- :flag-safety-concern is never excluded by this check, only FINALIZING/determining/clearing that concern is.

Actuation

Every proposal this actor generates is :effect :propose, never a direct actuation. Two independent layers enforce this (transitops.governor's effect-not-propose-violations HARD check and transitops.phase's phase table, which never puts :flag-safety-concern in any phase's :auto set). A human dispatch/ operations coordinator is always the one who actually acts on a flagged concern or confirms a high-cost maintenance order.

The core contract

route/vehicle/operator registration + dispatch-coordination request
        |
        v
   ┌───────────────────────┐   proposal      ┌────────────────────────────┐
   │ TransitDispatch-       │ ─────────────▶ │ UrbanTransitDispatch-       │  (independent system)
   │ Advisor (sealed)       │  + citations    │ Governor                    │
   └───────────────────────┘                 │ route-unverified ·          │
          │                 commit ◀┼ vehicle-unverified (dispatch only) · │
          │                         │ operator-unverified (dispatch only)·│
    record + ledger        escalate ┼ effect-not-propose ·                │
          │              (ALWAYS for│ scope-excluded (dispatch-safety-    │
          │       :flag-safety-     │ clearance / driver-fitness          │
          │       concern/high-cost │ finalization) · op-not-allowed      │
          │       maintenance order)└────────────────────────────┘
          ▼
      human approval

The TransitDispatchAdvisor never commits a proposal the UrbanTransitDispatchGovernor would reject, and a safety-concern flag or a high-cost maintenance order never commits without a human sign-off. Hard violations (an unregistered/unverified route; a dispatch-scheduling proposal naming an unregistered/unverified vehicle or operator; a non-:propose effect; content touching dispatch- safety-clearance-finalization or driver-fitness-to-drive-determination; an op outside the closed allowlist) force hold and cannot be approved past.

Robotics premise

All cloud-itonami verticals are designed on the premise that a robot may perform physical domain work (here: none directly -- this vertical's physical work, driving a bus/tram/railcar/taxi, is performed by a licensed human operator, not a robot) under human/robot floor operations gated by transit-authority policy. This actor itself does not dispatch robot/hardware actions and does not operate a vehicle -- it is strictly the scheduling/dispatch-logistics coordination layer (service-record logging, dispatch scheduling, maintenance-order coordination, safety-concern flagging) any physical- operations layer could eventually feed proposals into, always gated the same way by the independent UrbanTransitDispatchGovernor.

This is the beginning of the README. Read the rest at the original. Read the full README ↗