Safety-Case Writing Guide (DOC-P5)#

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

Scope: what Intended provides as a certified primitive, what the customer's safety case still has to argue, and how to write the argument.

What Intended is, in safety-case terms#

Intended provides a certified safety primitive — a building block the customer's safety case can claim. It is not a turnkey safety solution. The certification path applies to the **edge verifier binary

• JWKS retrieval + token claim enforcement**, not to your PLC, your safety bus, your motion controller, or your application logic.

Equivalent in safety-PLC terms: TÜV-certified function blocks. The function blocks have a safety integrity claim; the machine built out of them needs its own safety case.

What you can claim from Intended#

When you adopt Intended in your safety case, you may claim:

1. Authority gating is enforced at the edge. No state-changing action is dispatched without a valid Authority Token whose claims were checked against the operator's policy.

2. Tokens are bound to actor identity. A token issued for cobot-east-3 cannot be replayed on cobot-east-4 (assumes TOK-P5 IEEE 802.1AR DevID binding is enabled).

3. Tokens are time-bound. Tokens carry sub-second TTLs and the verifier rejects expired tokens against PTP-attested time (AUD-P7).

4. Safety-rated input attestation. When your PhysicalStateProvider surfaces predicates as safety_rated: true over a declared protocol (FSoE, PROFIsafe, Pilz PSS, OPC-UA Safety), the policy evaluator honors the rating; non-rated predicates cannot satisfy a clause that requires safety-rated input.

5. Audit chain coverage. Every issuance, denial, and edge verification result is recorded in a tamper-evident chain. Forensic replay against historical state is supported (DAG-P5).

6. Safe-default fallback. Every DAG node declares its safe-default action. On token denial, expiry, or audit-gap policy trip, the declared safe-default is emitted to the controller.

You may NOT claim:

• That Intended replaces your existing safety PLC or safety bus.
• That a safety case exists for the machine as a whole. That is your document.
• Any specific SIL / PL level for the machine — the Intended primitive has its own SIL claim, but the machine's level is determined by the weakest link.

Argument structure (GSN sketch)#

Goal Structuring Notation is one common approach. The top-level claim typically is:

G1: The machine satisfies <safety standard, e.g. IEC 13849 PLd>
    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: Risk reduction architecture mitigates each identified hazard.
        [strategy: argue over each risk-reduction layer]

    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.
            [strategy: argue over Intended certified primitive +
                       integration correctness]

      G1.2.2.1: The Intended edge verifier binary correctly enforces
                token claims against the operator policy.
                [evidence: TÜV assessment of Intended verifier
                           (when issued), Intended audit chain]

      G1.2.2.2: The customer's integration (predicate provider,
                actor identity binding, policy file) correctly
                surfaces machine state to the verifier.
                [evidence: integration test plan, traceability
                           matrix, code review records]

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

  G1.3: Implementation matches the architecture.
        [evidence: software bill of materials, change-control records]

  G1.4: Verification confirms the machine meets the safety claim.
        [evidence: test reports, validation by independent assessor]

The G1.2.2.x branch is where you cite Intended. The Intended primitive gives you cleaner evidence at G1.2.2.1 (someone else certified it). You still own G1.2.2.2 and G1.2.2.3.

Concrete deliverables for your safety case#

1. Integration design document#

Describes how Intended is wired into your machine. Minimum content:

• Block diagram showing where the edge verifier sits relative to the controller and safety bus.
• Sequence diagrams for normal operation, token denial, and audit-gap trip.
• The OIL category map: which machine actions correspond to which OIL codes, and what policy clause covers each.
• The actor identity binding mechanism (DevID provisioning, token-to- identity check).

2. PhysicalStateProvider correctness argument#

Your bridge from the safety bus to the Intended predicate set is safety-relevant. Argue:

• Each predicate maps to a single, named bus signal.
• The safety_rated flag is set true only when the signal is in fact safety-rated (cite the bus's certification).
• The protocol field accurately names the bus.
• Timing: as_of_timestamp_ms is set from a source whose freshness is bounded (cite the bus's update rate).
• Failure modes: when the bus is unreachable, the provider returns kind: unavailable, never a stale value.

3. Policy file and review record#

The Intended policy file (JSON) is part of your safety-relevant configuration. Treat it like ladder logic:

• Stored in version control with reviewed PRs.
• Each clause traces to a hazard in your hazard analysis.
• Changes go through your change-control board.

4. Latency and timing analysis#

Argue that:

• Cloud round-trip (issuance) does not happen on the RT path. (If it does, your safety case has a problem.)
• Edge verification fits inside the controller's RT cycle with margin. The verifier's worst-case execution time should be measured against your target hardware and documented.
• Safe-default actuation completes within the time budget the hazard analysis allows.

5. Time attestation argument#

Token expiry is checked against attested time. Argue:

• The time source (PTP grandmaster, NTP reference, GPS) is itself trustworthy in your operating environment.
• The verifier's clock cannot be rolled back by an attacker.
• Loss of time attestation results in a defined safe state, not in silent acceptance of expired tokens.

6. Failure mode analysis#

For each Intended-related failure mode, argue the machine's response is safe:

Common pitfalls#

• Claiming SIL coverage we don't yet provide. The Intended primitive has its own SIL trajectory. Don't claim higher than what the cert artifact supports at deployment time. Until TOK-P1 ships and is assessed, the claim is "best-practice authority gating," not "SIL-2 authority gating."

• Treating the policy file as configuration. It is not. It is safety-relevant logic and needs change-control parity with your PLC program.

• Surfacing camera-derived predicates as safety-rated. Vision is not a safety-rated input. If you need redundant human detection, use a safety-rated curtain or scanner alongside, and aggregate via the N-of-M consensus operator (ECE-P4).

• Forgetting the audit-gap policy. A robot that keeps moving when it can't reach the audit chain has lost its forensic-trail guarantee. Set time_bounded_audit_gap_policy.max_gap_ms to a value compatible with your factory's network reliability.

Standards crosswalk (informal)#

Working with assessors#

Bring this guide and the certification artifacts (when issued) to your assessor. The early conversation is "is this primitive credible enough to base a safety claim on?" Our answer: open-source SDK, open OIL taxonomy, signed reproducible binary, third-party assessment in progress. The assessor's call.

See also#

• DOC-P4 Rust safety-critical firmware — the verification contract you'll cite at G1.2.2.1
• DOC-P6 PLC migration — translating ladder patterns into Intended policy clauses
• docs/security/threat-model.md↗ — the STRIDE model the cloud product is built against