Part II — Recover Operating Subjects and Maintain Current State

OPS.3 - Distinguish Operating Subjects, Cases, Queues, Resources, and Records

OPS.3:0 - Use This When

Use this pattern when one card, ticket, order, object identifier, case file, event row, or status label is being asked to stand for several different things. Enter when a measure cannot say what it measures, a queue cannot say what waits, an incident record is treated as the incident, a resource is treated as its availability, or two views cannot agree because they identify their subjects differently.

The first useful move is to choose one decision-bearing subject and write:

Subject S is of kind K, with identity condition I. The decision-bearing claim Q about S and its relations R to Work and commitments is qualified for time or horizon T, supported by evidence E, and represented in record or view V. Missing identity or relation governor: G.

Repeat only for items whose distinction changes the decision. The result is a small operating-subject account, not a universal data model.

Recognition is cheap: enter when a record label, metric denominator, queue item, or “work object” has several plausible referents. Assurance is claim-specific: entity kinds, Work, relations, commitments, state, evidence, event occurrence, control participation, resource availability, and representation each retain their FPF or specialist tests.

Do not use OPS.3 to model every object in the operation, redesign a database, declare an event log complete, infer a case from a ticket, or create a catch-all operational object kind. If an existing subject pattern already answers the identity or relation question, use it and record only the Operations correspondence needed here.

OPS.3:0.1 - Working Distinctions

Name used here	Meaning
operating subject	The exact entity, relation, case subject, material, service, account, or other concern whose state or relation changes the operating decision. This is a reading position, not a new universal kind.
case	One bounded continuing Work situation organized around a named subject, commitments, current facts, evidence, authority, permissible next Work, and closure conditions. The case is neither its file nor every Work item within it.
Work occurrence	Actual dated Work admitted through its governing pattern. A ticket, plan, or event record does not establish that Work occurred.
Work item	A bounded item admitted to a selected workflow or coordination account with stated start, finish, subject/result relation, and receiving use.
queue membership	An obtaining relation placing one eligible item in one named waiting or service order under a policy and time window. A column or list is a representation.
buffer membership	An obtaining relation to a bounded protective or coordination reserve with purpose, policy, extent, and receiving use. It is not inferred from spare inventory or a board column.
resource relation	The exact availability, access, consumption, support, allocation, or other relation through which a System, capability, material, information, time, or condition is used by Work. The resource and relation remain distinct.
event	An occurrence or change under its subject rule and time boundary. An event record or timestamp is evidence about it, not the event by identity.
record or trace	A claim-bearing episteme about subjects, Work, events, relations, or decisions, recorded on an identified carrier. Its claims have stated sources and scope limits.
state claim	A qualified claim about one subject at a stated time or horizon with provenance, uncertainty, conditions, and authority. A status label is one possible representation.
control participant meaning	Observer, controller, plant, or supervisor as the participant meaning in one actual direct relation and selected control structure. The label is not a universal kind or proof that the relation obtains.
operating-subject account	The smallest relation-specific set of identities, direct relations, records, state claims, and explicit gaps needed by the current operating decision.

OPS.3:1 - Problem Frame

Operational tools compress the world so people can coordinate. That compression is useful until one row is read as the customer, order, case, Work, queue position, resource claim, event history, and current state at once. Object-centric and case-responsive approaches repair parts of this problem, but their own records and identifiers still need receiving-use limits.

The practitioner needs a small account that restores identity and obtaining relations before measures and policies are applied. The account can use several records and views while keeping the world-side subjects and claim-bearing epistemes distinct.

OPS.3:2 - Problem

When identities collapse, flow measures acquire false denominators, cases close while the conditions they were meant to resolve persist, queue policies compare unlike items, resources are double-counted, and events are reconstructed into Work that may never have occurred. A record update can then masquerade as an operational change.

The opposite failure is an enterprise ontology project. It delays action, imports tool categories as truth, and still may omit the few direct relations that the current decision consumes.

OPS.3:3 - Forces

Force	Tension
Coordination shorthand	One ticket or identifier is affordable, while it can hide several subjects and relations.
Measurement	Stable units enable comparison, while identity changes and joins can silently change the measured population.
Several records	Logs, trackers, files, and physical observations can complement one another, while their claims may conflict.
Runtime change	Cases and subjects evolve, while records arrive late or use stale identity rules.
Resource scarcity	Capacity decisions need resource relations, while people and machines must not be reduced to scalar capacity.
Minimality	The operation needs decisive distinctions now, while a complete domain model is expensive and brittle.

OPS.3:4 - Solution

Build the smallest operating-subject account that preserves exact identities, obtaining relations, time, evidence, and representation for the current decision. Start from the subjects and views selected by OPS.1 and OPS.2; add no item merely because a source schema contains it.

OPS.3:4.1 - Pattern-Use Unfolding

Name the receiving decision and suspected compression. Name the two items being treated as the same, the measure, queue, case continuation, commitment, control question, or account use that depends on that identity assumption, and what fails if the assumption is false.
Select the primary subject. Name the entity or relation whose state changes action and its identity condition across time. Use its direct subject pattern when kind membership is load-bearing.
Separate case, Work, and Work item. Name the case subject and closure conditions; admit actual Work independently; define each coordination Work item by start, finish, subject/result relation, and receiving use.
Recover queue and buffer relations. Name eligible item, queue or buffer, membership interval, order or protective purpose, policy, resource/service relation, and evidence. A drawn position creates none of these facts.
Recover resources through exact relations. Distinguish the System, capability, material, information, access condition, or time from availability, access, allocation, support, consumption, or other obtaining relation. Preserve authority and human-condition questions.
Separate events, records, and state claims. Identify the occurrence or changed subject; identify each record and carrier; state what claim it supports, source, time, uncertainty, and limit. Do not reconstruct Work from event order alone.
Recover commitments and direct relations. Use A.6.REL or the direct governor for each relied-on relation. Keep promise, obligation, fulfilment, responsibility, authority, assignment, and evidence distinct.
Apply the control branch only when selected. Preserve actual Systems or holons and direct observation, actuation, reference, supervision, and feedback relations. Treat observer, controller, plant, and supervisor as relation-specific meanings. Use B.2.5 only when both observation/report and returned influence/constraint sides obtain.
Reconcile records by subject and claim, not by row. State correspondences, conflicts, missing joins, identity changes, currentness limits, and which source can support which decision. Keep unresolved claims visible.
Stop at the smallest sufficient account. Return exact subjects, direct relations, records, state claims, gaps, and reopen conditions to OPS.4. Leave unrelated objects outside.

OPS.3:4.2 - Record the Result

Result position	Required content
use boundary	User, decision, horizon, suspected compression, and useful stop.
subjects and identity	Exact primary and related subjects, governing kinds or predicates, identity conditions, and unresolved referents.
cases and Work	Case subject and closure; actual Work basis; Work-item start/finish, subject/result relation, and receiving use.
queue, buffer, and resource relations	Participants, membership or access interval, purpose/policy, order or extent, direct relation, and evidence.
events and records	Occurrences, claim-bearing records and carriers, source, scope, time, uncertainty, and non-admissible inferences.
state and commitments	Qualified state claims, commitment relations, provenance, authority, conflicts, and currentness.
control relations	Actual participant meanings and observation/actuation/reference/supervision/feedback relations, or an explicit `not current` result.
continuation	Account content supplied to OPS.4, explicit gaps, and observable reopen conditions.

OPS.3:4.3 - What Changes in Practice

Measures, queues, and dashboards acquire named subjects and relation semantics. A card move updates the record. Separately establish any change in the subject or relation that the updated record represents. Teams can keep several tools while knowing which claim each can support and where a missing identity or relation blocks action.

OPS.3:5 - Archetypal Grounding — PumpWorks Subject Account

The weekly release decision initially sees four cards and a rig calendar. OPS.3 expands only the distinctions that change action:

Visible item	Recovered subject or relation	Record boundary
`ReleaseCandidate-R42` card	A release-candidate subject and its candidate contents, required evidence results, release Work items, and receiving release decision.	The card and commit identifiers are records; moving the card does not change deployed field state or satisfy the release commitment.
`FieldIncident-I73` ticket	A case organized around `FieldPumpInstallation-P4`, reported symptoms, service commitments, evidence, authority, permissible next Work, and closure conditions.	Ticket closure does not establish restored field condition or fulfilled service.
`SafetyQuestion-S19` issue	A question episteme, related evidence needs, specialist safety decision, and any Work items created to obtain that result.	A red label is neither a safety state nor authority to accept risk.
`ProviderChange-P8` epic	A time-bounded change subject with provider relations, access conditions, project WorkPlan content, affected release cases, and decisions.	The epic does not make the provider part of PumpWorks or prove performed migration Work.
test-rig booking row	Queue membership of an exact eligible request for resource relation to `TestRig-2`, with interval, order/policy, access condition, and status evidence.	The booking row records planned access. Establish request eligibility, allocation authority, performed test Work, and test completion separately.

Records remain distinct: ticket, trace, source commit, build result, test result, service log, field-engineer report, telemetry record, and release decision each support bounded claims. A multi-object event record may relate one event to several subjects, but it does not identify those subjects with one case or prove the represented Work.

For the product-side control view, FieldPumpInstallation-P4, FieldTelemetryObserver-O4, DeployedController-C17, and FieldModeSupervisor-S1 retain their relation-specific meanings. For operating supervision, ReleaseSupervisorTeam-S2 is an admitted acting System only where supported and the two-sided report/constraint relation to PumpWorks-ControlServiceOps is recorded only if both sides obtain. The diagram, participants, relations, state claims, and operating account remain distinct.

The result supplies OPS.4 with exact subjects, records, current claims, conflicts, permissions and refresh needs. Reopen only the affected identity or relation when a release candidate is superseded, an incident splits or merges under an explicit rule, a queue membership changes, a record source becomes stale, or a claimed control relation loses one side.

OPS.3:6 - Bias-Annotation

Recurring bias	Likely drift	Repair
card-identity bias	Card, case, Work item, and subject become one thing.	State separate identities and direct relations.
case-file bias	The file becomes the continuing case.	Name the subject, commitments, current facts, permissible Work, and closure conditions.
queue-container bias	A column or list is treated as an obtaining queue.	Recover membership, order/service relation, policy, interval, and evidence.
resource-scalar bias	A person, machine, or capability is reduced to available hours.	Preserve the subject and exact access, support, allocation, or use relation.
event-log realism	A log is treated as complete performed Work.	Preserve source limits and admit Work independently.
object-centric collapse	Multi-object linkage is read as one universal case or process.	Keep subjects, event relations, records, views, and receiving uses distinct.
control-role reification	Observer, controller, plant, or supervisor labels become permanent kinds.	Recover participant meanings in exact obtaining relations.

OPS.3:7 - Conformance Checklist

The account begins from one receiving decision and a named suspected compression.
Each decision-bearing subject has an identity condition and direct subject governor when needed.
Case, actual Work, Work item, queue membership, buffer membership, resource, event, record, and state claim remain distinct.
Work items state start, finish, subject/result relation, and receiving use.
Queue, buffer, and resource claims name exact participants, purpose or policy, interval, and obtaining relation.
Records state source, carrier, claim scope, time, uncertainty, and non-admissible inference.
Direct relations use current governors; a representation or co-occurrence creates none.
Control participants and two-sided feedback are recorded only where actual relations obtain.
The result is the smallest account sufficient for the decision and names gaps and reopen conditions.

OPS.3:8 - Common Anti-Patterns and How to Avoid Them

Anti-pattern	Repair
“One issue equals one unit of value.”	Name the represented subject, Work item, result relation, identity rule, and receiving decision.
“The customer is in the queue.”	State whether the queued participant is a request, case, Work item, physical subject, or another exact entity.
“The resource is 80% utilized.”	Identify the resource subject, availability/allocation/use relation, time window, Work, and decision.
“The event log shows the process.”	State the logged events, object relations, source coverage, reconstruction rule, and missing Work evidence.
“Status Done means fulfilled.”	Recover the commitment, supplied result, acceptance or fulfilment evidence, and authority separately.
“The dashboard closes the feedback loop.”	Recover both in-life relation sides and keep the display, claims, rates, and proof separate.

OPS.3:9 - Consequences

The pattern produces trustworthy units for measurement and policy and makes cross-view reconciliation possible. It also localizes repairs: a stale record source, changed identity rule, missing relation, or uncertain state claim can reopen without rebuilding the whole operating account.

The cost is refusing convenient conflations. Some metrics and historical analyses become unusable because their unit identity or source coverage cannot be recovered. That loss is explicit rather than hidden in a precise-looking chart.

OPS.3:10 - Rationale

Operations decisions act on subjects and obtaining relations, while coordination normally uses records and representations. Keeping those layers distinct preserves practical speed without allowing tool schemas to decide ontology. A minimal relation-specific account is enough when it names what can change the decision and what remains unsupported.

OPS.3:11 - SoTA-Echoing

Practice question	Selected current line and serious alternative	Defect overcome and governed loci	Source roles and limits	Reopen condition
What is the smallest operating account that preserves decision-bearing subjects and relations across cases, queues, resources, events, and records?	The selected current line is subject- and relation-first, multi-object where needed, with records and events retained as qualified evidence. The serious default is case-ID, ticket, schema, or event-log first, where one recorded identifier or serialization becomes the operating subject.	The default creates false identities, denominators, completion claims, and causal or state inferences. Adapt: `OPS.3:4.1` recovers exact subjects and direct relations, `OPS.3:4.2` records representation and evidence limits, `OPS.3:4.3` localizes repair, and `OPS.3:5` tests several unlike subjects. Reject: record closure, event order, shared fields, or one case identifier as sufficient world-side state.	OCEL and object-centric process management are the best-known-line candidates for escaping one-case convergence in event data. CMMN and DCR are serious bounded case/constraint alternatives; DEMO contributes commitment and coordination distinctions; current FPF governs obtaining relations and claim-bearing accounts. These sources do not prove performed Work, current world state, causal effect, or one universal operating ontology.	Reopen if a stronger current account or repeated use preserves the same identities, direct relations, provenance, uncertainty, and local repair at lower effort, or if a source changes the minimum multi-object or record-use distinction.

The selected comparison is supported by the following bounded source roles and limits.

Source line	Retained contribution	Use boundary
Current FPF `A.6.REL`, `C.2.1`, `B.2.5`, and direct subject patterns	Recover obtaining relation occurrences, claim-bearing epistemes, two-sided supervision relations, and subject-specific identity.	FPF does not choose Operations subjects, domain queues, records, service commitments, or intervention consequences.
CMMN 1.1 and DCR	Preserve changing case facts, discretionary planning, milestones, and declarative condition/response relations.	A case plan or constraint model is not the case subject, performed Work, or complete Operations Method.
OCEL and object-centric process management	Relate events to several objects and retain object histories instead of forcing one case identifier.	OCEL 2.1 adds serializations to the OCEL 2.0 model; neither an event log nor an object link establishes the world-side operation, complete Work, or one universal case.
DEMO 2020/2024, see the source account	Distinguish production and coordination Work, transaction roles, commitments, responsibility, and result relations.	Source-local transaction constructs do not become general FPF relation kinds or a complete operating ontology.
Integrated material, transaction, information, financial, and relation-specific network sources, see the source account	Preserve several connected, non-isomorphic structures for one decision.	Shared nodes or proximity do not create one universal flow or network identity.

OPS.3:12 - Relations

OPS.1 supplies operating scope, subject candidates, commitments, units, and evidence questions. OPS.2 supplies selected views, grains, correspondences, and conditional control questions.
A.6.REL and direct subject patterns govern obtaining relations and identities; C.2.1 governs claim-bearing accounts; B.2.5 and C.30.LCA govern the conditional control relation/view boundary.
OPS.4 consumes exact subjects, direct relations, records, state claims, provenance, conflicts, permissions, and gaps.
OPS.8, OPS.9, OPS.10, OPS.11, OPS.12, and OPS.18 later consume the exact subjects and relations whose queue, constraint, capacity, interaction, human-condition, or quality claim is current.
Data engineering, process mining, product engineering, safety, finance, law, medicine, and other specialists retain their schemas, inference Methods, evidence, and authority.

OPS.3:End

OPS.4 - Keep Current Operating State Recoverable Across Participants

OPS.4:0 - Use This When

Use this pattern when people must coordinate continuing Work but act from stale, partial, conflicting, differently authorized, or differently grained accounts of the same operating subjects. Typical cues are “we need one source of truth”, a control room with no claim provenance, a board that hides field state, a case handoff that loses the next decision, or a dashboard whose users cannot tell what they may change.

The first useful move is to create or repair one participant-usable account for one decision:

For subjects S and commitments C, current claims are Q at horizons T, supported by E with provenance and uncertainty P; participants may read or change ...; disagreements and gaps are G; next decisions or permissible Work are N; refresh or expiry occurs under R.

Aligned attention does not require identical screens or consensus. It requires that participants can recover the subjects, qualified claims, evidence, permissions, disagreements, and next decision relevant to their Work.

Recognition is cheap: enter when a participant cannot resume, decide, or explain a material disagreement from the maintained account. Assurance is claim-specific: world state, evidence, authority, permission, Work, safety, stability, causal effect, and release or acceptance decisions keep their own governing patterns.

Do not use OPS.4 to build a generic dashboard, mandate transparency, create one shared mental model, replace specialist records, or declare state true because it is visible. If the current problem is a Work-performance configuration or recovery dependency after interruption or support loss, use A.15.8 for that general question and keep the operation-specific state and commitments here.

OPS.4:0.1 - Working Distinctions

Name used here	Meaning
current operating account	A participant-usable set of qualified claims tied to exact operating subjects, commitments, evidence, permissions, decisions, and refresh conditions. It is neither the operating System nor a universal database.
subject-state claim	A claim about one exact subject or relation at a stated time or horizon, with scheme, conditions, provenance, uncertainty, and authority.
currentness	The condition under which a claim remains usable for a named decision and horizon. Recent timestamps alone do not establish it.
provenance	The source, observation, transformation, record, and responsibility facts needed to judge the claim’s receiving use. Provenance does not make the claim true by itself.
uncertainty	Missing, estimated, conflicting, stale, or bounded information whose reach can change action.
disagreement	Two or more recoverable claims, interpretations, or decisions that cannot yet be used as one result. Visibility of disagreement is compatible with aligned attention.
permission and change authority	Separately supported relations governing who may read, write, approve, hold, release, or otherwise use account content. Visibility, responsibility, assignment, and capability imply none of one another.
next decision or permissible Work	The decision or Work option currently enabled, blocked, or awaiting a named condition. The account does not perform or authorize it by display.
participant view	A use-bounded representation of selected account claims for one participant action. Several views may coexist when subject and claim correspondence remain recoverable.
control representation	A view, loop diagram, dashboard, or control-room display representing selected control structures, relations, rates, or account claims. It establishes none of those facts by appearance.
attention-maintenance result	The smallest repaired current account, participant views, gaps, refresh rules, and next-decision returns that let the named participants coordinate.

OPS.4:1 - Problem Frame

Continuing operation needs a present account because the operation outlives one meeting, screen, shift, or model session. Claims arrive at different rates from field observations, cases, tests, providers, plans, queues, and specialist decisions. Different participants need different slices and hold different authority.

The aim is therefore not one display or total agreement. It is recoverable correspondence between exact subjects, qualified claims, evidence, permissions, disagreements, and the next decisions each participant must make.

OPS.4:2 - Problem

Visibility without claim discipline amplifies error. A fresh dashboard can repeat stale field state, a green board can hide an unresolved service commitment, and an integrated twin can merge observations with predictions and planned states. Participants appear aligned until a decision exposes different referents, time horizons, or authority.

The opposite failure stores every record and overwhelms users. Important gaps, conflicts, and expiry conditions disappear in detail, so people reconstruct state from memory or private channels.

OPS.4:3 - Forces

Force	Tension
Speed	Participants need a quick current view, while rushed aggregation can erase provenance and uncertainty.
Several horizons	Field control, incident response, release, provider change, and finance update at unlike rates.
Several participants	People need different views and permissions, while divergence can hide conflicting claims.
Continuing Work	Handoffs and interruptions require recoverability, while an account cannot guarantee capability or performance.
Disagreement	Teams want one answer, while preserving a qualified conflict can be safer than premature consensus.
Representation	Dashboards and control rooms improve attention, while appearance can be mistaken for state, authority, or proof.

OPS.4:4 - Solution

Maintain the smallest decision-specific account that lets named participants recover exact subjects, current qualified claims, commitments, evidence, uncertainty, permissions, disagreements, next decisions, and refresh conditions. Present several views when needed, but keep claim and subject correspondence explicit.

OPS.4:4.1 - Pattern-Use Unfolding

Name participants and decisions. State who must resume, coordinate, hold, release, escalate, or perform next Work; name the horizon and useful stop for each action.
Import exact subjects and relations. Use the OPS.3 operating-subject account. Do not let a dashboard row, case file, queue position, or control diagram replace the subject or obtaining relation.
Select only decision-changing claims. For each subject or commitment, state the current claim, effective scheme, conditions, time or horizon, and action it can change.
Attach evidence and provenance. Name source, observation or result, carrier, transformation, version, evidence reach, and uncertainty needed for reliance. Keep prediction, plan, observation, and decision claims distinct.
Expose conflict and absence. Preserve incompatible claims, missing observations, stale evidence, unknown authority, and unresolved specialist returns. Do not average them into false agreement.
Recover permissions and authority. State who may read, write, annotate, accept, hold, release, or change each relied-on claim or decision. Keep assignment, capability, responsibility, permission, and authority separate.
State next decisions and permissible Work. Name what is enabled, blocked, awaiting evidence, or returned to a specialist; include the condition and participant that can advance it.
Construct participant views. Select the smallest representation for each action. Preserve subject identity and claim correspondence; show what the view omits and where claims conflict, and provide a return to the owning account. Do not require one screen.
Keep control views separate. A selected FPF control view may expose observer, controller, plant, supervisor, observation, actuation, feedback, and rates. The account carries qualified operating claims about those subjects and relations; the view or loop picture establishes neither current state, feedback closure, rate adequacy, stability, safety, authority, nor an Operations Method.
Test interruption and handoff when current. Use A.15.8 for the general Work or WorkPlan performance-configuration question. Ask a representative next participant to recover the bounded question, current claims, evidence, disagreements, permissions, next Work, and stop without private memory.
Refresh, expire, and reopen. State update sources, expected cadence or event, expiry rule, supersession and conflict handling, and the observation that reopens only the affected claim, view, or decision.

OPS.4:4.2 - Record the Result

Result position	Required content
use boundary	Participants, actions or decisions, horizons, first useful result, and truthful stops.
subjects and commitments	Exact OPS.3 subjects and direct relations; commitment parties, content, conditions, status, and authority.
current claims	Claim content, effective scheme, time/horizon, conditions, uncertainty, and receiving action.
evidence and provenance	Sources, observations/results, carriers, transformations, versions, reach, and missing evidence.
permissions and authority	Read, write, annotate, accept, hold, release, and change relations with their scope and basis.
disagreement and gaps	Conflicting or missing claims, affected decisions, specialist returns, and non-admissible compression.
next decisions and Work	Enabled, blocked, awaiting, or returned actions; required condition and responsible participant.
participant views	Selected claims, subject correspondence, explicit scope of omitted material, conflict cues, return route, and access limits.
refresh and recovery	Update or expiry conditions, handoff/recovery observation when current, and smallest reopen rule.

OPS.4:4.3 - What Changes in Practice

Participants stop asking whether everyone sees the same dashboard. They ask whether each participant can recover the exact subjects, claims, evidence, permissions, disagreements, and next action needed for that participant’s decision. A visible conflict or honest unknown becomes a usable coordination result. A record update no longer masquerades as changed world state.

OPS.4:5 - Archetypal Grounding — PumpWorks Current Operating Account

The weekly release decision uses a small account rather than one status board:

Account claim	Evidence, uncertainty, and authority	Next decision or Work
`FieldIncident-I73` may affect controller behavior at `FieldPumpInstallation-P4`.	Field-engineer report and telemetry record are current to different times; lab reproduction is absent; service-impact extent is disputed. Field service may update observations but cannot accept product safety.	Continue bounded diagnosis, obtain lab evidence, and keep release effect unresolved.
`ReleaseCandidate-R42` passed tests `T1–T8`; `T9` remains blocked by rig access.	Signed test results identify candidate and fixture versions; the test-rig booking is current but does not prove a completed test. Release authority remains separate.	Await exact rig access and `T9`; no release from card status.
`SafetyQuestion-S19` has no current specialist decision.	The issue record contains a question and evidence request, not a safety verdict. Only the named safety authority can return the needed result.	Hold the affected release use or narrow its scope under the current authority rule.
`ProviderChange-P8` changes model-artifact access after the current window.	Contract and technical-access records disagree on effective date.	Resolve the access relation or choose the supported incumbent route.
Weekly evidenced-release commitment is at risk.	Incident, test, provider, and release claims have different horizons and authority. The account displays the relation without collapsing them into one status.	Release, hold, rollback, narrow, or renegotiate only through the corresponding authority and evidence.

The product-side control view separately represents FieldTelemetryObserver-O4, DeployedController-C17, plant FieldPumpInstallation-P4, FieldModeSupervisor-S1, and their direct relations where supported. The operating-supervision view separately represents reports from PumpWorks-ControlServiceOps and constraints returned by ReleaseSupervisorTeam-S2. The separately qualified temporal claims concern sub-second product control, minute-to-hour field observation, daily incident triage, weekly release, and slower provider change.

The OPS.4 account may cite claims about those participants, relations, and rates. The control diagram does not establish their current state, two-sided feedback, stability, safety, release authority, or the account itself. A dashboard can display the release hold and missing T9; it does not create either fact.

For a shift or model-session handoff, the next participant must recover the operating question, five subject claims above, evidence versions, unresolved conflicts, permissions, next permissible Work, and stop. If recovery requires private memory or an unrecorded chat, A.15.8 returns the exact missing carrier, update/use relation, cue, or support condition. OPS.4 then repairs the operation-specific account claim or view.

Reopen only the affected claim when new telemetry arrives, T9 completes, safety authority returns a decision, provider access changes, a commitment is renegotiated, or a participant view can no longer support its action.

OPS.4:6 - Bias-Annotation

Recurring bias	Likely drift	Repair
single-source-of-truth bias	One database or screen is treated as the world and final authority.	Preserve exact claims, provenance, conflicts, permissions, and receiving decisions.
visibility-as-alignment bias	Everyone can see the board, so coordination is assumed.	Test whether each participant can recover the next decision and disagreement.
consensus bias	Conflicting qualified claims are forced into one status.	Keep disagreement explicit with evidence reach and resolution condition.
freshness bias	The newest timestamp is assumed current for every horizon.	State claim-specific currentness and expiry for the receiving use.
access-authority bias	The ability to edit or view is treated as authority to decide.	Recover permission and decision authority separately.
representation-as-control bias	A loop or control room is treated as feedback closure or operating Method.	Recover actual relations and keep view, account, rates, and stronger claims distinct.
memory-repair bias	People or models are told to remember more after handoff failure.	Use A.15.8 to recover the missing state, carrier, update/use relation, cue, or support condition.

OPS.4:7 - Conformance Checklist

The account begins from named participants, decisions/actions, horizons, and useful stops.
Exact OPS.3 subjects, commitments, and direct relations remain recoverable in every relied-on view.
Each current claim states content, scheme, time/horizon, conditions, evidence/provenance, uncertainty, and receiving action.
Observation, prediction, plan, record, decision, and world-state claims remain distinct.
Disagreements, missing observations, stale evidence, and specialist returns remain visible with their decision reach.
Read, write, annotate, accept, hold, release, responsibility, capability, and authority relations are not inferred from one another.
Next decisions and permissible Work name their enabling or blocking conditions.
Participant views preserve subject and claim correspondence, make omitted scope and claim conflicts visible, and provide a return to the owning account.
A control representation establishes none of current state, feedback closure, rate adequacy, stability, safety, authority, or Method.
Refresh, expiry, supersession, handoff/recovery observation when current, and smallest reopen rules are explicit.

OPS.4:8 - Common Anti-Patterns and How to Avoid Them

Anti-pattern	Repair
“Build one dashboard for everyone.”	Start from participant actions and select claims and views for each, with correspondence and return.
“Green means done.”	Recover the subject state, commitment, evidence, acceptance or fulfilment result, and authority.
“Latest update wins.”	Apply claim-specific currentness, source reach, conflict, and supersession rules.
“Make everyone agree.”	Preserve qualified disagreement and name the evidence or authority needed for resolution.
“If it is editable, the team owns it.”	Separate access, permission, responsibility, assignment, and decision authority.
“The control room closes the loop.”	Recover the in-life relation sides and rate claims; treat the display as a representation.
“The handoff failed because attention was low.”	Identify the missing subject claim, carrier, update/use relation, cue, permission, or stop.

OPS.4:9 - Consequences

The pattern improves continuation across shifts, tools, teams, and interruptions without requiring one representation or consensus. It makes uncertainty and disagreement actionable and lets views change without losing subject identity.

The cost is explicit provenance, permission, conflict, and refresh maintenance. Some attractive dashboards become secondary because they cannot preserve the claim and authority distinctions needed by the decision.

OPS.4:10 - Rationale

Shared attention is an operating achievement when participants can coordinate from qualified claims about the same subjects and commitments. That achievement is weaker than universal agreement and stronger than common visibility. A small decision-specific account preserves the distinction, while FPF continues to govern epistemes, evidence, Work-performance recovery, structures, and control claims.

OPS.4:11 - SoTA-Echoing

Practice question	Selected current line and serious alternative	Defect overcome and governed loci	Source roles and limits	Reopen condition
How should participants maintain shared attention to current operating state without treating visibility as truth, agreement, authority, or control?	The selected current line is a small decision-specific account of qualified claims with provenance, uncertainty, permissions, conflicts, participant views, next action, and refresh. The serious default is a single real-time dashboard, latest record, or “single source of truth” used as the shared state.	The default hides stale or incomparable claims, erases qualified disagreement and authority, and lets a display stand for world state or feedback closure. Adapt: `OPS.4:4.1` selects claims from participant actions, `OPS.4:4.2` returns a refreshable account, `OPS.4:4.3` permits honest conflict and local repair, and `OPS.4:5` tests handoff and recovery. Reject: common visibility or edit access as sufficient evidence, agreement, permission, or control.	Current FPF supplies the account, evidence, recovery, temporal, and control boundaries. Kanban is the official comparator for bounded workflow visibility; OCEL and object-centric work preserve several histories; DORA, harness, and loop sources supply fast-changing AI-assisted-operation cases; layered-control/LCA sources expose relation and rate distinctions. None establishes a universal shared-state carrier, authority model, or effectiveness result.	Reopen if a stronger current coordination account or repeated handoff case achieves the same provenance, conflict, authority, refresh, and recovery value with lower burden, or if a source changes the minimum claim content or account/control boundary.