Safety-Case Writing#

Audience: functional-safety engineers writing the deployment-specific safety case for a machine that uses Intended for authority gating.

Scope: what Intended provides today, what the customer's safety case still has to argue, and how to write the argument honestly.

What Intended is, in safety-case terms#

Intended provides mechanisms a safety case can cite: structured-goal classification, policy evaluation over attested machine state, short-lived signed tokens, an escalation/approval workflow, and a tamper-evident audit trail. It is not a turnkey safety solution, and — stated plainly — it carries no functional-safety certification today.

What you can claim today#

When you adopt Intended, you may claim that the following mechanisms are in place and evidenced by the audit chain:

1. Authority gating is enforced before dispatch. No state-changing action your integration gates is dispatched without a token whose claims your controller checked.
2. Tokens carry a bound actor identity. Each token's sub / actorIdentity names the actor it was issued for; the actor must be registered on the tenant roster before issuance. (Hardware-anchored DevID binding is a customer provisioning step.)
3. Tokens are time-bound. A token's lifetime is the action's deadlineMs (sub-second), and your verifier rejects expired tokens — against attested time once you integrate PTP/NTP.
4. Safety-rated input attestation is honored. When your PhysicalStateProvider surfaces a predicate as safetyRated: true over a declared protocol (FSoE, PROFIsafe, Pilz PSS, OPC-UA Safety), a clause requiring safety-rated input will not be satisfied by an untrusted or unavailable channel.
5. Every decision is recorded in a tamper-evident chain. Issuance, denial, and escalation are all auditable. The chain is a per-tenant SHA-256 hash chain; evidence export is HMAC-signed with the tenant's own secret — verification requires possession of that secret, so it is not publicly/asymmetrically verifiable.
6. Safe-default fallback is declared per node. On denial, expiry, or an audit-gap trip, the deciding clause carries the declared safe-default for your controller to actuate.

You may NOT claim:

• That Intended replaces your safety PLC or safety bus.
• That a safety case exists for the machine — that is your document.
• Any SIL / PL level, or any third-party assessment, for an Intended component.
• That audit evidence is independently/publicly verifiable — it is HMAC-keyed to the tenant secret.

Argument structure (GSN sketch)#

The top-level claim typically reads:

G1: The machine satisfies <safety standard> for the hazard
    <H1: unintended motion> in operating mode <M1>.

  Strategy: argue over (a) hazard analysis, (b) risk reduction,
            (c) implementation, (d) verification.

  G1.1: Hazard analysis identified all credible sources of unintended motion.
        [evidence: HAZOP / FMEA / STPA records]

  G1.2: The risk-reduction architecture mitigates each identified hazard.

    G1.2.1: Safety-rated e-stop chain interrupts power on operator request.
            [evidence: certified safety-PLC, FSoE bus, commissioning report]

    G1.2.2: Authority gating prevents motion without explicit, classified,
            time-bound authorization.

      G1.2.2.1: Token claims are checked before dispatch and rejected when
                invalid/expired.
                [evidence: controller code review, bench test, Intended audit chain]

      G1.2.2.2: The customer integration (predicate provider, actor-identity
                binding, policy file) correctly surfaces machine state.
                [evidence: integration test plan, traceability matrix]

      G1.2.2.3: On denial / expiry, the controller transitions to the declared
                safe-default within <bounded time>.
                [evidence: latency measurement, controller code review]

  G1.3: Implementation matches the architecture.  [evidence: SBOM, change control]
  G1.4: Verification confirms the safety claim.    [evidence: test reports]

The G1.2.2.x branch is where you cite Intended's mechanisms — but the evidence at G1.2.2.1 is your own (controller review, bench test, the Intended audit chain), not a third-party certificate, because none exists yet. You own G1.2.2.2 and G1.2.2.3 outright.

Concrete deliverables#

1. Integration design document — block diagram of where verification sits relative to controller and safety bus; sequence diagrams for normal operation, denial, and audit-gap trip; the OI category map (which machine actions map to which OI codes and which clause covers each); the actor-identity binding mechanism.
2. PhysicalStateProvider correctness argument — each predicate maps to one named bus signal; safetyRated is set true only when the signal is genuinely safety-rated (cite the bus certification); protocol names the bus accurately; asOfTimestampMs comes from a bounded-freshness source; on bus loss the provider returns kind: unavailable, never a stale value.
3. Policy file and review record — version-controlled with reviewed PRs; each clause traces to a hazard; changes go through change control.
4. Latency and timing analysis — the cloud round-trip (issuance) is off the RT path; verification fits the controller's RT cycle with margin; safe-default actuation completes within the hazard-analysis budget.
5. Time-attestation argument — the time source is trustworthy in your environment; the verifier clock cannot be rolled back; loss of attestation yields a defined safe state.
6. Failure-mode analysis — for each Intended-related failure, argue the machine's response is safe:

Common pitfalls#

• Claiming certification you don't have. Until an Intended component is actually assessed, the claim is "best-practice authority gating." Do not write SIL/PL levels or assessor names for Intended into your case.
• Treating the policy file as mere configuration. It is safety-relevant logic; give it change-control parity with your PLC program.
• Surfacing camera-derived predicates as safety-rated. Vision is not a safety-rated input. For redundant human detection, use a safety-rated curtain/scanner and aggregate with an N-of-M consensus clause.
• Forgetting the audit-gap policy. Set audit_gap.max_gap_ms to a value compatible with your network reliability; a robot that keeps moving with a broken audit trail has lost its forensic guarantee.

Standards crosswalk (informal — no certification implied)#

This maps where the mechanisms fit, not where Intended is certified. No row below asserts an assessment.

Working with assessors#

Bring this guide. The early conversation is "is this mechanism credible enough to base a safety argument on?" The honest answer: open-source SDK, open OI taxonomy, signed tokens, tamper-evident audit chain — and no third-party safety assessment yet. The assessor's call, made on your machine's full case, not on a certificate Intended does not hold.

See also#

• Rust safety-critical firmware — the verification contract you cite at G1.2.2.1.
• PLC migration patterns — translating interlocks into policy clauses.
• Authority API reference — the audited surface your case describes.