Safety Observation Schema

Machine-readable contract: /schemas/safety-observation.schema.json · Used by: safety-observation-agent, triage-agent, shift-handover-agent

Full JSON Schema

The machine-readable contract is served at /schemas/safety-observation.schema.json. Key points: additionalProperties: false (unknown fields are rejected), required fields are observedAt, reportedBy, area, observationType, observationSummary, safetyStatus, immediateRouting, authorityLimits, notAuthorizationStatement, and area, observationType, safetyStatus, and immediateRouting are constrained to enums.

This is a capture-and-route record in the agent contract layer: it pairs with the Plant Issue Intake schema for reported problems and the Shift Handover schema for carry-forward, and it inherits the limits in the safety guardrails. It is a record, not an action plan — it records what was observed and where it was routed, and authorizes nothing.

Valid example

A routine safety observation captured neutrally and routed to the site safety authority — without deciding any corrective action or declaring anything safe. Values are qualitative; no thresholds or numeric values.

{
  "observationId": "SO-2026-0627-014",
  "observedAt": "2026-06-27T09:15:00Z",
  "reportedBy": "Production supervisor",
  "area": "finish-mill",
  "equipmentOrLocation": "Walkway near Finish Mill 2 access stair",
  "observationType": "housekeeping",
  "observationSummary": "Spilled material and a loose hose noted along the walkway, narrowing the path; no one was observed at risk at the time.",
  "safetyStatus": "possible-concern-routed-to-authority",
  "immediateRouting": "site-safety-authority",
  "relatedHandover": "/schemas/shift-handover",
  "evidenceAvailable": [
    "photo of the walkway",
    "location note"
  ],
  "missingInformation": [
    "Has the area supervisor been notified directly?",
    "Is the hose part of active work or left over?"
  ],
  "routedTo": [
    "Site safety authority",
    "Area supervisor"
  ],
  "followUpOwner": "Site safety authority",
  "authorityLimits": [
    "Does not authorize any corrective action, cleanup task, or field work.",
    "Does not authorize operation, shutdown, restart, or any LOTO decision.",
    "Does not declare the area or condition safe and makes no compliance or legal determination."
  ],
  "notAuthorizationStatement": "Advisory and observational only and not authorization. Any corrective action, clearance, or safety decision requires the appropriate human authority under site procedure."
}

Invalid example (and why)

This is what a safety observation must not look like. It oversteps the observational boundary in several ways.

{
  "observedAt": "2026-06-27T09:15:00Z",
  "reportedBy": "Production supervisor",
  "area": "control-room",
  "observationType": "slip-hazard",
  "observationSummary": "Walkway cleared and inspected.",
  "safetyStatus": "area-is-safe",
  "immediateRouting": "supervisor",
  "correctiveAction": "Locked out Finish Mill 2 and sent a crew to clean and clear the walkway for work."
}

Why it fails:

• Declares something safe. safetyStatus: "area-is-safe" is a clearance and is not an allowed enum value. The record never declares a condition safe; safetyStatus is a routing status only.
• Authorizes field work and corrective action. The correctiveAction text locks out equipment, dispatches a crew, and clears an area for work. An observation routes to an authority; it never authorizes cleanup, field work, LOTO, or any corrective action.
• Adds an unknown field. correctiveAction is an extra property; with additionalProperties: false it is rejected — and authorizing action is never the record’s to do.
• Uses bad enum values. area: "control-room" is not in the allowed enum (use utilities or other), and observationType: "slip-hazard" is not allowed (use housekeeping or access-egress).
• Drops required fields. authorityLimits and notAuthorizationStatement are missing, so the not-authorization guardrails are absent.

Versioning

Semantic version in version. Additive changes (new optional fields) bump the minor version; any breaking change (new required field, removed/renamed field, tightened enum) bumps the major version and should ship under a new $id.