Features / Behavioural safety
Observed behaviour → cited policy → defensible action, on one audit trail.
Behavioural safety is where compliance meets labour relations — and where most EHS platforms fall down. A supervisor witnesses a behaviour. The behaviour matches (or violates) a policy clause. A consequence follows, escalating with prior history. Two months later, an arbitrator reviews. The platform's job: chain of custody from observation to letter is documented, the policy text cited is the policy text that was approved at the time, and the escalation is countable — not "supervisor judgment." SE ships a four-outcome observation model, a citation-grounded policy clause registry, a most-specific matching engine that prevents double-discipline, counted progressive discipline with configurable lookback windows, and a disciplinary-letter lifecycle that snapshots boilerplate at issue so policy edits never rewrite delivered letters.
The policy-linked work-observation-item catalogue, drilled into one behaviour item — the running product against Apex Manufacturing demo data. On-screen captions narrate each step.
What's in it
The capability surface.
Four-outcome observation model
- Compliant — default-positive; the observed behaviour matched the rule.
- NonCompliant — rule violation; opts into the discipline engine when the observation template's per-outcome follow-up flag is set.
- NotApplicable — the rule didn't apply to the observed situation; captured for compliance-rate reporting (denominator awareness).
- Recognized — above-and-beyond positive; supervisor exemplary-behaviour callout.
- Observed-at and recorded-at are distinct — supervisors walk the floor at 10:00 and record at lunch; both timestamps survive in audit.
- The recorder's identity is immutable once saved; supervisors can edit notes / outcome / evidence after the fact, but can't reattribute or backdate.
Observation templates
- Tenant-scoped templates that operationalise a policy clause (or manually-authored behavioural rule) into a binary checkpoint a supervisor records during inspections or mobile catches.
- Allowed outcomes — a subset of the four outcomes; a PPE check might allow [Compliant, NonCompliant, NotApplicable] while a behavioural-praise checkpoint might allow [Recognized, Compliant].
- Tags — multi-valued freeform categorisation that drives discipline-policy matching (no closed 7-category taxonomy; tenants author their own).
- Source policy-clause references — optional, multi-valued. A template can be manually authored (no clause references) or derived from extracted policy clauses, with traceability for the citation chain.
- Per-outcome follow-ups — each outcome can carry a supervisor cue plus a feeds-discipline flag; at most one follow-up per outcome.
Policy-clause registry
- Tenant-scoped registry of clauses extracted from policy documents (employee handbook, code of conduct, safety plans).
- The literal clause text, suitable for direct inclusion in disciplinary letters, plus a title for indexing.
- Applicability scope — Employees / Contractors / Visitors / Public / All.
- Citation — source quotation + page context; provenance — source document, timestamp, and method; a grounded flag — true for manual entries, with AI-extracted entries carrying verified grounding from the AI extraction pipeline.
- Status — Proposed → Approved / Rejected, with a reviewer + timestamp + review-notes audit trail.
Disciplinary policy + most-specific resolution
- Tenant-scoped escalation policies. Match a specific policy clause (clause-strict) OR a tag category (tag-fuzzy). Optional site narrowing.
- Most-specific resolution — when a single observation matches multiple policies, the engine breaks ties via specificity ranking: clause-strict + site-specific (score 4) → clause-strict + tenant-wide (3) → tag-fuzzy + site-specific (2) → tag-fuzzy + tenant-wide (1).
- Tiebreak within the same tier — the oldest policy wins. Deterministic; admin authoring order is the natural priority.
- Result — one case per observation, not one case per overlapping policy. No double-discipline from rules that happen to share a category.
Counted progressive discipline
- Each policy carries an ordered list of steps (Verbal Warning → Written Warning → Issue Disciplinary Letter → Suspend → Terminate, configurable per policy).
- The engine counts prior matching observations against the same worker — same outcome, matching clause / tag, within the lookback window if one is set (no window = all-time).
- The count picks the step — 2 prior matches means the 3rd offence fires the 3rd step.
- Past the last step the policy is exhausted; no infinite escalation.
- Guardrail — if a policy includes Terminate, it must be the final step; the engine refuses to escalate past Terminate.
Disciplinary-case lifecycle
- Site-scoped. Created by the discipline engine in Pending state when an observation crosses a policy threshold; HR reviews before activation.
- Lifecycle — Pending → Active (HR activates) → Resolved, with a Dismissed fork from any non-terminal state.
- Immutable snapshot frozen at case creation — the resolved step, the resolved policy, and the prior-offence count. Survives policy edits made after creation. The case carries the decision as data, not as a reference that drifts.
- A back-pointer to the originating observation; the subject is the worker the case is against.
Discipline actions — six kinds, one fully real
- On case activation, the discipline engine looks up the action matching the case's resolved step and runs it.
- Verbal Warning — audit-only today; records the event; the HR-system write is deferred.
- Written Warning — audit-only today; written-warning document rendering deferred.
- Issue Disciplinary Letter — fully real; creates a disciplinary letter in Draft state and notifies HR to pick it up.
- Suspend — audit-only today; directory-account deactivation + payroll integration deferred.
- Notify Authority — audit-only today; outbound notification to police / regulator deferred.
- Terminate — audit-only today; HRIS + payroll integration deferred.
Dedicated Behavior-Based Safety (BBS) module
- A branded BBS entry surface at
/bbs— built on the same observation history as the rest of the platform. BBS observations aren't a separate data island; they're a shape of observation with two fields the BBS methodology cares about. - Intervention type — Coaching (verbal redirect in the moment), Formal correction (documented warning, pairs with the discipline engine), Reinforcement (positive callout for exemplary safe behaviour), or None. Defaults to None for non-BBS observations so the legacy mobile-capture surface keeps working unchanged.
- Risk-reducing behaviour — free-text capture of the safe behaviour the observer coached or recognised. The positive surface BBS methodology asks for: capture what worked, not just what didn't.
- Captured as a standard observation used by mobile capture and inspection walk-throughs — no double-entry, no second source of truth. A BBS metrics dashboard is live: percent-compliant by site, observer, and observation item, with the lowest-compliance items surfaced first.
- Reuses the existing observation permissions, template + outcome rules, and site-scope contract.
Disciplinary letter + letter template
- Lifecycle — Draft → Reviewed → Issued → Acknowledged, with Rescinded reachable from any non-Rescinded state.
- Cited policy clauses — HR picks the clauses the recipient allegedly violated; the clauses' approved text gets embedded in the rendered letter.
- Narrative — HR-written case-specific prose (what was observed, when, by whom, expectations going forward, corrective action).
- Tenant-scoped letter template — title, description, severity (Warning / Final Warning / Termination Notice), plus intro / outro / signature-block snippets.
- Per-recipient language — each letter template can carry per-locale boilerplate variants. At issue, the letter freezes the variant matching the recipient's preferred language; English fields stay as the fallback when no variant matches. Partial variants supported — a tenant can override just the signature block for a locale while keeping the English intro and outro.
- Template snapshot freeze on Issue — the intro / outro / signature snippets are captured on the letter at the Reviewed → Issued transition. Post-issue template edits never rewrite delivered letters.
- Optional signed-PDF acknowledgement — HR uploads the recipient's signed copy.
- Full audit fields — authored, reviewed, issued, acknowledged, and rescinded (each with who + when), plus a rescission reason.
Representative workflows
What this looks like in practice.
PPE violation → 3rd offence → disciplinary letter, end-to-end
The Site Safety Officer catches an operator running a press without safety glasses. From a tablet: opens the "PPE — Eye Protection" template, picks the subject, picks NonCompliant, attaches a photo, saves. The discipline engine picks up the observation; that template's NonCompliant follow-up feeds discipline; the engine resolves the most-specific matching policy — a clause-strict tenant-wide policy on "Eye Protection in Press Areas", ranked above a tag-fuzzy "ppe" policy. Within the 365-day lookback: 2 prior matches → 3rd offence → Issue Disciplinary Letter. A Pending case is created with resolved step + policy + prior count frozen on the record. HR reviews, activates; the engine drafts a letter with the clause text embedded + the template boilerplate referenced. HR writes the narrative, picks "Final Warning", marks Reviewed → Issued. The intro / outro / signature snippets freeze on the letter — a future template edit never rewrites it. The operator acknowledges; the signed PDF uploads. If six months later an arbitrator asks "what policy text did this letter cite?", the answer is the clause text at the time of issue + the snapshot on the letter — not a reconstruction.
Recognised behaviour — the Recognized outcome (the platform isn't just for violations)
The next day, the same Officer catches a different operator stopping his press to re-lock a guard that had slipped — clearly above-and-beyond. Opens the "Machine Guard Engagement" template (allows [Recognized, Compliant]), picks Recognized. The observation enters the audit trail like any violation — but the Recognized follow-up doesn't feed discipline and carries a supervisor cue ("Verbal kudos; consider monthly recognition program nomination"). The discipline engine ignores the event; no case opens. The operator's recorded recognitions become a positive surface in their performance file. Most platforms model observations as violations-only; SE treats positive behaviours as first-class outcomes — same audit trail, same supervisor flow, same tag reporting. Cultural buy-in from line workers who'd otherwise read "observations" as "gotchas."
Policy refresh — in-flight cases reference the prior approved version
Six months in, the safety committee updates the "Eye Protection in Press Areas" clause — new language about face-shield requirements alongside eye protection. The Tenant Admin edits the clause body; the last-updated timestamp updates. The in-flight disciplinary case is unaffected — its policy snapshot was frozen at case creation, and the Issued letter already has the prior clause text embedded via the at-issue snapshot. The arbitrator hearing the case three months later sees the policy as it was when the case was opened, not as it is now. New observations after the edit reference the updated body. The clause's own history is auditable through the audit-event trail.
How this is different
What sets behavioural safety + policy enforcement apart.
Most EHS platforms ship behavioural-safety modules as a checklist app — a list of observation categories, a way to flag good vs bad, and a manual workflow for escalation. SE built it as the front end of a litigation-defensibility pipeline. The differences below are direct consequences of treating "did we cite the right policy text and run the escalation by the rules" as the floor an EHS platform has to clear, not the ceiling.
The citation is in the letter, not in a sidebar
Most platforms generate a disciplinary letter as a form with placeholders — supervisor types "employee violated policy X" + the letter renders. SE's disciplinary letter carries its cited policy clauses as a first-class field; the rendering layer embeds the clause's approved text directly into the letter, not as a reference. The letter document, frozen at issue, contains the exact policy paragraph that was approved at the time, fetched from the same registry the supervisor saw on the floor. If the arbitrator asks "show me the policy this letter says was violated," the answer is in the letter itself — not a separate database lookup that may have drifted.
Most-specific policy resolution prevents double-discipline
Two policies match the same observation — one tag-fuzzy on "ppe", one clause-strict on the "Eye Protection in Press Areas" clause. A naive engine fires both, opening two cases against one offence. SE's most-specific resolution ranks matches by 4-tier specificity (clause-strict + site = 4 → clause-strict + tenant = 3 → tag-fuzzy + site = 2 → tag-fuzzy + tenant = 1), oldest policy winning a tier-tie. One case per observation, deterministically, "winning" policy traceable on the record. Admins stack policies as they grow without worrying about double-discipline from rule overlap.
Progressive discipline is counted, not judged
"Three strikes" sounds simple but becomes a debate inside HR — was the verbal warning twelve months ago really a strike, or a coaching moment that got logged? SE counts prior matching observations of the same outcome against the same worker, with the policy's lookback window as the eligibility window; the count maps deterministically onto the ordered step list. Step three is whatever the policy's third step is, not whatever the manager thinks is appropriate. Lookback encodes the org's tolerance (PPE policies might lookback 365 days; conduct policies all-time); the step kinds encode escalation; the count + index + outcomes do the rest. HR judgment goes into the Narrative + the activation gate — not into "is this offence count right."
Templates snapshot at issue, never rewrite delivered letters
Six months after an Issued letter, the Tenant Admin updates the letter-template boilerplate to include a new corporate signature block. SE freezes the rendered intro / outro / signature on the letter at the Reviewed → Issued transition; the post-issue edit changes the template for future letters but never retroactively touches the delivered one. Attempts to change title, template, cited clauses, or narrative on a non-Draft letter are rejected. What was delivered yesterday is what's recorded today — the snapshot pattern is the structural guarantee.
Observations include positive callouts
Most platforms model behavioural observations as violations-only. SE ships Recognized as a first-class outcome — same audit trail, same supervisor flow, same tag reporting, with the discipline engine opting out via that outcome's follow-up not feeding discipline. Line workers stop reading "observations" as "gotchas" because they see their own positive behaviours logged with the same dignity. EHS managers get a denominator for compliance-rate math (you can't compute 95% compliance without knowing the 5% population). And a worker's record carries both directions — not just the bad days.
Adjacencies
What behavioural safety connects to.
Incidents
Discrete relation today — an observation captured during incident investigation is a separate observation record, not an incident sub-type. Incident-to-disciplinary-case linkage is on the roadmap for cases where an incident's contributing factors include a documented behavioural violation.
Explore →
Hazards
Separate paths — hazards drive corrective actions; observations drive discipline. A single workplace situation can produce both (the unguarded machine + the operator who entered it). Cross-linking is roadmap.
Explore →
Policy extraction (AI)
SE's AI pipeline extracts policy clauses from uploaded policy documents with grounded citations; reviewer approval gate (Proposed → Approved) before live. AI-suggested observation-item generation from approved clauses is the next AI step on the roadmap.
Explore →
Notifications
Case-activation + letter-Issued + recipient-acknowledged events all flow through the notification layer with in-app + logging defaults today; production email / Slack / Teams channels are sequenced next.
Auditing
Every observation + case + letter transition produces an audit event in the platform's audit log. Same foundation as the rest of the platform — query + retain + export per tenant policy.
Multi-tenant + role separation
Observation scope = site; observation templates / policies / letter templates scope = tenant. Per-role permission split: supervisors record observations; admins author observation templates, disciplinary policies, and letter templates; HR manages disciplinary cases and letters.
On the roadmap
What's next for behavioural safety.
Everything above is shipped and ready to demo. These are the focused next additions for this area, sequenced by customer demand.
Continue exploring
More on the SE platform.
Five live feature spokes + two roadmap pages + the Workers' Comp claims roadmap. Jump anywhere.
See the observation-to-letter chain in the running product.
A 30-minute walk-through against your actual policy + observation shape — your industry, your existing policy corpus, your progressive-discipline framework, your current observation tooling. We'll show the four-outcome observation flow + the most-specific policy resolution + the letter lifecycle, all on a single audit trail.