Work Operating Model
Use this page when you need to understand how Helpifyr turns work into a real terminal outcome instead of a projected or local-only green state.
What this concept means
- work is not complete just because one runtime, page, or projection says it looks complete
- work type determines which gates, approvals, and readbacks are required
- closeout claims stay fail-closed until the owning truth surfaces agree
- human review stays explicit when the policy or work type requires it
Why it exists in the Helpifyr stack
Helpifyr separates execution from closeout authority. A runtime may do work, a projection may summarize work, and a local workflow may look green, but terminal completion still depends on the owner-defined closeout path.
That keeps operators from treating a generated status surface as if it were the same thing as owner-cleared truth. It also keeps cross-repo work reviewable when multiple systems have to agree before the result can be called done.
What it is not
- not a second runtime
- not a shortcut around owner review or approval rules
- not permission to claim success from Pattern projection alone
- not a replacement for product-specific runbooks or contracts
Core objects and boundaries
Work type
Work type determines whether the next step is safe automation, controlled action, required human approval, or a blocked path.
Projection versus closeout truth
Pattern can materialize and render work state, but projection is not the final closeout authority. Fabric owns the contract-level gate and verdict semantics used to determine whether a terminal claim is valid.
Owner readback
Terminal completion often depends on required owner readbacks. If a downstream system, approval surface, or synchronization check has not confirmed the result, the work item is not yet complete.
Human gate
Some work types require explicit human approval, escalation, or closeout review. That gate should stay visible rather than being collapsed into a generic status field.
Relationship to other concepts
- Human Interaction explains where approval and escalation stay mandatory.
- Identity, Session, and Projected Authority explains why visible access posture is not the same thing as final authority.
- Mission Control and Operator Context explains how the human-facing shell may summarize work without becoming the owner of final truth.
- Runtime Projection and Readback explains why projected state still needs source revision and readback discipline before closeout.
- Platform Truth explains where contract and publication truth are owned.
- End-to-End Flows shows how these boundaries appear in cross-service execution paths.
Source truth and evidence
helpifyr-fabric/contracts/work_operating_model/work_operating_model_v1.jsonhelpifyr-fabric/contracts/work_operating_model/work_type_gate_matrix_v1.jsonhelpifyr-fabric/contracts/work_operating_model/agent_closeout_policy_v1.jsonhelpifyr-fabric/contracts/work_operating_model/agent_autonomy_policy_v1.json