Skip to main content

Identity, Session, and Projected Authority

Use this page when you need to understand how Helpifyr publishes access, session, and admin posture without letting downstream runtimes invent rights or silently turn partial auth wiring green.

When to use this page​

  • You need to know who owns business access truth, technical auth truth, and runtime materialization.
  • You are checking whether a surface is truly ready, merely followthrough-required, or still blocked.
  • You need the public-safe boundary between projected authority and the runtime that consumes it.

Prerequisites​

  • You have read System Model.
  • You want the access-projection model that sits underneath auth, session handoff, and fail-closed admin posture.

Architecture / Flow​

Step-by-step procedure​

1. Separate rights ownership from runtime materialization​

Helpifyr keeps identity truth split on purpose.

Typical boundaries are:

  • business access truth owned by Spindle
  • technical auth truth owned by Heddle
  • runtime materialization owned by the surface runtime owner
  • projection and fail-closed verdict truth owned by Fabric

2. Treat projection as the readable authority posture​

Fabric projects each current surface into one explicit access and onboarding view so operators and downstream repos do not guess:

  • auth mode
  • onboarding status
  • session handoff mode
  • admin-capable posture
  • readiness verdict
  • fail-closed reason codes

3. Keep session and admin posture explicit​

Session handoff is not one generic green state. It may be:

  • an interactive OIDC session
  • a bridge handoff
  • a runtime-local auth session
  • a host-local admin session
  • a planned-but-not-live session contract

Likewise, superadmin and recovery-only admin posture must stay machine-readable instead of living only in runtime UI configuration.

4. Fail closed when authority or lifecycle truth is incomplete​

Published surface visibility does not mean authority is safe to consume.

Readers should expect explicit blocked or review-required posture when:

  • projection is stale
  • a session shape is planned but not materialized
  • local or bridge auth still needs normalization
  • runtime materialization exists but rights truth is not aligned

Verification​

This page is being applied correctly when a reader can:

  1. explain who owns rights truth, auth truth, runtime materialization, and projection truth
  2. distinguish projected readiness from actual runtime ownership
  3. explain why incomplete session or admin posture must stay fail-closed

Common failure modes​

Treating a visible surface as proof that authority is live​

Problem:

  • a surface appears in docs or ingress and readers infer a complete auth, claims, and session posture from visibility alone.

Better path:

  • check projected readiness, session handoff mode, and fail-closed reasons before assuming access is truly live

Treating projected authority as permission to redefine rights locally​

Problem:

  • a downstream runtime or UI invents local rights semantics because it already consumes one projected access shape.

Better path:

  • keep rights truth with the owning identity system and use Fabric projection only as the canonical read-only posture surface

Source Truth​

Next paths​