Part I — Bound the Operation and Select Coordination Views

OPS.1 - Identify the Operating System, Commitments, and Flow Units

OPS.1:0 - Use This When

Use this pattern when people want to improve a process, clear a backlog, raise utilization, accelerate flow, or redesign a board but cannot yet name the operation whose result must continue. Typical warning signs are an organization name used as the operating boundary, one ticket called the customer need, a queue column treated as the Work, or a service promise discussed without its parties, conditions, or horizon.

The first useful move is to write one bounded operating-focus statement:

For this decision and horizon, OperatingSystem-X must continue supplying Result-or-Service-Y; current demand and commitments are ...; the decision-bearing subjects and counted units are ... under these identity rules; the unresolved boundary, authority, evidence, or control question is ....

That statement is useful before a workflow, target, priority, or policy is chosen. It gives OPS.2 a real coordination question and gives OPS.3 exact subjects to distinguish.

Recognition is cheap: enter when a practical decision cannot name its operating System, continuing result, commitments, or tracked unit. Assurance is claim-specific: System identity, commitment, Work, subject identity, authority, evidence, safety, value, and effectiveness use their own governing patterns and specialist Methods before reliance.

Do not use OPS.1 merely to rename an already bounded operation, classify every object as a System, approve a strategy, design a product, authorize Work, or choose an improvement Method. If the current blocker is a product or asset change, organization change, one person’s capability, finance, law, safety, or another specialist result, obtain that result and return only if it changes the operating focus.

OPS.1:0.1 - Working Distinctions

Name used here	Meaning
operating System	One actual System whose continuing operation and results are current for the decision. It is not inferred from an organization name, process diagram, product label, software tool, or reporting boundary.
continuing result or service	The result, service, or preserved condition the operation must keep supplying to a named receiver under stated conditions. Continuation does not prove value, quality, acceptance, or fulfilment.
demand	A request, need, condition, candidate Work claim, arrival, or other input entering the operating decision. Demand is not automatically admitted Work or a commitment.
commitment	A promise or obligation with parties, promised result or service, conditions, horizon, authority, and current status. A due date or priority label alone is not a commitment.
operating subject	The exact System, item, case subject, material, service relation, account, or other entity whose state or relation can change the operating decision.
flow or case unit	A decision-specific counted or tracked unit with an identity rule and receiving use. Treat Work items, cases, physical items, batches, transactions, commitments, and results as different units unless their identity rules and evidence establish that the labels denote the same counted or tracked unit for this use.
operating boundary	The included subjects, Work, resources, relations, environments, and time horizon needed for this decision, plus explicit exclusions and specialist returns.
control-relevant operating concern	A question in which observation, decision, actuation, supervision, feedback, or unlike rates can change current coordination. It is an entry cue for an FPF control view, not a kind of operation.
operating-focus result	The bounded result returned by OPS.1: operating System, continuing result, demand, commitments, subjects and units, boundary, evidence or authority gaps, next pattern, and reopen condition.

OPS.1:1 - Problem Frame

Operations work begins in the middle. Demand has arrived, commitments already exist, cases are open, resources are shared, records disagree, and service must continue while changes are considered. Familiar representations make that situation look simpler than it is. A board foregrounds Work items, an organization chart foregrounds positions, a process map foregrounds recurring order, and a product model foregrounds the engineered object.

Answering the operating question may require several of these representations. A useful starting boundary therefore comes from the continuing result and present decision, then identifies the actual operating System, commitments, subjects, and units needed to decide.

OPS.1:2 - Problem

Without an operating focus, later optimization can improve the representation while degrading the operation. A team can shorten one board column while customer cases age, increase resource utilization while service commitments fail, count ticket closures while the field condition persists, or optimize product-control performance while release and incident-response Work remain blocked.

The failure propagates. Queue, constraint, capacity, quality, service, finance, and Method-improvement decisions inherit the wrong boundary and unit.

OPS.1:3 - Forces

Force	Tension
Urgency	A visible backlog invites immediate action, while an incorrect operating boundary makes the action locally efficient and globally harmful.
Familiar names	Company, team, product, service, platform, and process names help orientation, while none alone identifies the operating System.
Several commitments	Customer, safety, provider, release, support, and financial commitments can coexist without one being the universal priority.
Countability	Boards and logs offer convenient units, while convenience does not establish identity or receiving use.
Continuing service	The operation must act with incomplete evidence, while uncertainty does not license invented state or authority.
Bounded entry	The first result must be affordable, while later decisions need enough identity and boundary precision to avoid rework.

OPS.1:4 - Solution

Limit the operating focus to what the current decision needs; identify the actual System, continuing result, relevant commitments, and subject/unit boundary. Begin from the result that must continue, not from a preferred board, workflow, metric, or school.

OPS.1:4.1 - Pattern-Use Unfolding

Name the first user and decision. State who needs the focus, what decision it enables, the relevant horizon, and the first useful result or honest blocker.
List materially different operating-System candidates. Consider the whole organization, a service operation, production cell, development operation, hospital function, supply relation, personal operation, product or asset, and coordination software when each is plausible. Use A.1.SCR only when System identity changes the decision; otherwise name the actual subject and leave through its pattern.
State the continuing result or service. Name its receiver, conditions, horizon, and the observation that would show interruption or degradation. Keep value, quality, acceptance, fulfilment, safety, and causal effect as separate claims.
Recover demand and commitments. Distinguish requests and candidate Work from admitted Work. For each decision-bearing commitment, name parties, promised result or service, conditions, horizon, authority, current status, and evidence gap.
Name operating subjects. Identify the customers, cases, physical items, release candidates, incidents, transactions, materials, services, accounts, or other subjects whose state or relation changes action.
Define every tracked unit. State the unit’s identity rule, start and finish when it is a Work item, subject/result relation, counted interval, and receiving use. Do not call every unit a flow item merely because a board counts it.
Draw the operating boundary. Include only the Work, resources, relations, environments, and time horizon needed by the decision. Name excluded product, organization, asset, finance, legal, safety, capability, and other specialist questions with their return conditions.
Check the control branch. If observation, decision, actuation, supervision, feedback, or rate separation can change coordination, record the control-relevant operating concern for OPS.2. Do not construct a control view or infer a feedback relation here.
Recover authority and evidence limits. Name who may use the focus for which decision, what evidence supports it, what remains uncertain, and which missing fact blocks reliance.
Return, dispose, and reopen. State the selected operating focus, rejected candidates, next pattern, truthful stop, and one observable change that reopens the boundary, commitment, subject, or unit. When a change reopens any focus field, list the known downstream views, accounts, policies, and later decisions that consumed that field; mark each recheck, still usable, or return, and give the decision-local reason. Leave an unrelated consumer intact.

OPS.1:4.2 - Record the Result

Result position	Required content
use boundary	First user, decision, horizon, first useful result, and truthful stop.
operating-System candidates	Candidate referents, decisive identity and boundary facts, selected System or subject-pattern return, and rejected alternatives.
continuing result or service	Receiver, result or preserved condition, operating conditions, interruption observation, and unresolved value, quality, safety, or acceptance claims.
demand and commitments	Demand classes; commitment parties, contents, conditions, horizons, authority, status, and evidence gaps.
subjects and units	Exact subjects, unit identity rules, Work-item start/finish where relevant, subject/result relations, and receiving uses.
boundary and returns	Included Work, resources, relations, environments, horizon, exclusions, and specialist results needed.
control concern	The decision-changing observation, actuation, supervision, feedback, or rate question, or an explicit `not current` result.
continuation	Next useful pattern and an observable reopen condition.
downstream disposition	Every known view, account, policy, or later decision that consumed a changed focus field, marked `recheck`, `still usable`, or `return` with its reason; unrelated consumers remain intact.

OPS.1:4.3 - What Changes in Practice

The practitioner stops treating “the process”, backlog, service label, or reporting unit as self-evident. Every later view, queue, capacity measure, or intervention must refer to one operating System, a continuing result, explicit commitments, and units whose identity and use are known. A missing boundary or commitment becomes a useful blocker before a policy change accumulates cost.

OPS.1:5 - Archetypal Grounding — PumpWorks Continuing Control Service

PumpWorks must continue weekly evidenced controller releases while field incidents, provider changes, test-rig access, safety questions, and service commitments coexist.

Candidate	Disposition for this decision
PumpWorks company	Too broad; corporate, financial, and legal questions remain specialist returns.
controller product	An engineered product and possible plant/controller participant, not the operation coordinating its continuing service.
field installation	A product-use and service subject whose state matters, not the whole release-and-incident operation.
board and issue tracker	Representations and records used by the operation; neither acts as the operating System.
`PumpWorks-ControlServiceOps`	Selected operating System because its continuing Work coordinates evidenced releases, incident response, provider change, rig access, and service commitments.

The continuing results are usable evidenced releases and truthful incident/service responses, not card movement or software deployment alone. Current demand includes ReleaseCandidate-R42, FieldIncident-I73, SafetyQuestion-S19, ProviderChange-P8, and test-rig requests. They are not one unit kind.

The weekly release commitment names the product/service receivers, required evidence, release horizon, release authority, and hold conditions. Incident response has different parties and horizons. Provider access and safety review have their own commitments and authority. OPS.1 records each without ranking them by label.

The operating subjects include the release candidate, field installation, incident case, safety question, provider change, rig booking, evidence results, and service relation. A release-candidate Work item may be counted for one workflow; the incident case and field pump remain separately identified. The selected boundary excludes product redesign, safety acceptance, corporate finance, and provider-contract decisions except as named returns.

Unlike rates make a control concern current: sub-second product control, minute-to-hour field observation, daily incident triage, weekly release, and slower provider change can affect the release decision. OPS.1 passes that concern to OPS.2 without declaring a control structure, feedback closure, stability, safety, or a universal control Method.

Reopen the focus if the operation’s continuing result changes, field-service Work makes another System the decision bearer, a commitment’s parties or authority change, or the current units cannot preserve subject identity across the next decision.

Suppose ProviderChange-P8 becomes a separately authorized provider-transition operation rather than Work inside PumpWorks-ControlServiceOps. Recheck the OPS.2 migration-project view and the OPS.4 provider-access and authority claims because they consumed that boundary. Keep the release-validation process view and the FieldIncident-I73 case account usable while their subjects, commitments, and relations remain unchanged. Return provider-contract authority to its specialist owner. The focus record carries these three dispositions instead of discarding every downstream result.

OPS.1:6 - Bias-Annotation

Recurring bias	Likely drift	Repair
process-name bias	“The release process” becomes the operating System.	Start from the continuing result and compare exact System candidates.
organization-boundary bias	A department or company name fixes the operation.	Recover the Work and relations that make the bounded operation relevant.
ticket-as-subject bias	The record becomes the customer, product, incident, or commitment.	Name the represented subject and the record relation separately.
commitment-by-date bias	A due date or service target is treated as an obtaining promise or authority.	Recover parties, content, conditions, horizon, status, and authority.
unit-of-value bias	Every counted item is called value or flow.	State identity and receiving use; use the source-local term only within its boundary.
controller-name bias	A controller product makes every operating question a control question.	Enter the control branch only when control relations or rates change coordination.

OPS.1:7 - Conformance Checklist

The opening names a first user, operating decision, horizon, and useful stop.
The operating System is selected from materially different candidates or the result truthfully returns to another subject pattern.
The continuing result or service names its receiver and conditions without declaring value, quality, safety, acceptance, or fulfilment by wording.
Demand, commitments, admitted Work, subjects, records, and units remain distinct.
Every decision-bearing commitment names parties, content, conditions, horizon, authority, status, and evidence limits.
Every counted or tracked unit has an identity rule and receiving use.
The boundary names included Work and relations, exclusions, specialist returns, and evidence or authority gaps.
A control concern is recorded only when it can change the decision; no diagram or controller label establishes it.
The next pattern and one observable reopen condition are explicit.
A reopened focus gives every known consumer of the changed field a recheck, still usable, or return disposition and leaves unrelated consumers intact.

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

Anti-pattern	Repair
“Optimize the whole value stream.”	Name the operating System, receiver, result, subjects, and exact selected transformation-flow structure before optimizing.
“The backlog is demand.”	Distinguish external demand, candidate Work claims, admitted Work, deferred demand, and records.
“One ticket equals one customer outcome.”	Recover the customer or service subject, case, Work items, results, and record relations.
“All urgent items have commitments.”	Recover the actual promise or obligation and its authority; urgency and queue rank are separate.
“The board is our operating model.”	Treat the board as a representation; select the operation and decision before choosing views.
“The controller is the operation.”	Keep the engineered controller, controlled plant, service operation, control structure, and operating account distinct.

OPS.1:9 - Consequences

The pattern prevents premature optimization and gives later patterns stable subjects, commitments, units, and return conditions. It also exposes when the useful next result belongs to product engineering, organization change, maintenance, finance, safety, law, capability development, or another specialist practice.

The cost is early boundary and identity work. Some urgent requests stop because no one can support the operating System, commitment, unit, authority, or evidence claim. That is cheaper than optimizing a proxy whose relation to the continuing result is unknown.

OPS.1:10 - Rationale

Continuing operation is coordinated through actual Systems, Work, relations, commitments, and results. A board, process description, metric, or school can help only after its subject and use are fixed. Beginning from the continuing result and decision makes the boundary small enough to use while preserving the distinctions later queue, constraint, capacity, quality, service, and improvement decisions consume.

OPS.1:11 - SoTA-Echoing

Practice question	Selected current line and serious alternative	Defect overcome and governed loci	Source roles and limits	Reopen condition
How should a practitioner establish the first operating focus before changing a board, policy, measure, or flow?	The selected current line is subject-, commitment-, and decision-first: bound the operating System or subject, continuing result, commitments, operating subjects, tracked units, authority, and evidence before selecting a management Method or representation. The serious default is workflow- or school-first: take an existing process, value-stream, backlog, board, or branded Method as the operation and its items as the units.	The default can optimize a representation or convenient count while the service, case, product, or commitment degrades. Adapt: `OPS.1:4.1` and `OPS.1:4.2` require a decision-bounded focus and consumer disposition; `OPS.1:5` demonstrates selection and local reopening; `OPS.1:7` checks that downstream consumers are rechecked without discarding unaffected results. Reject: a board, school, or source-local unit as the operating boundary by default.	FPF supplies System, relation, account and evidence distinctions. This pattern connects Work, Methods and the viewpoints needed for the operating decision. The Kanban Guide describes a bounded workflow. TameFlow and DEMO also examine commitments, hidden queues, interactions and coordination Work. Use these accounts to compare proposed operating boundaries.	Reopen if a stronger current comparison or repeated unlike use shows that a workflow-first entry preserves the same subject identity, commitments, specialist returns, downstream repair locality, and decision value at lower effort, or if a relied-on source changes one of those moves.

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

Relate Methods, performed Work, resources and the structures selected for the operating question. Projects, processes, cases and queues can expose different features of that Work.

Source line	Retained contribution	Use boundary
Current FPF `A.1.SCR`, `A.6.REL`, `C.2.1`, and `A.10`	Conditional System recognition, obtaining relations, claim-bearing accounts, and evidence reliance.	FPF does not select the Operations result, commitments, domain units, intervention, or service consequence.
The Kanban Guide 2025.5	Define a workflow and its Work items explicitly before using flow measures or active-item policies.	One minimal Kanban Method does not identify every operating System, case, commitment, physical subject, or suitable management view.
TameFlow 2022 and its precursor, see the source account	Distinguish optional demand from committed Work and make hidden queues, constraint, financial, interaction, and human-condition questions visible.	The four concerns do not create four transformation-flow kinds or one universal operating boundary.
DEMO 2020/2024, see the source account	Make production and coordination Work, commitments, parties, responsibility, and transaction structure visible.	DEMO constructs remain organization-specific source contributions and do not become FPF ontology or a complete Operations Method.

OPS.1:12 - Relations

A.1.SCR governs conditional System recognition; OPS.1 consumes that result and adds the operating continuation, commitment, subject, and unit boundary.
A.6.REL and direct subject patterns govern obtaining relations. C.2.1 governs persisted claim-bearing accounts; a focus statement creates neither relation nor world state.
OPS.2 consumes the operating System, commitments, subjects, units, decision questions, and any control-relevant concern. OPS.3 consumes subject candidates, commitments, evidence questions, and identity gaps.
OPS.5 later consumes the eligible demand and current commitments for admission; OPS.15, OPS.17, and OPS.19 later consume the operating scope for account, repertoire, and simultaneous-Work decisions.
Product engineering, OCE, Maintenance, HCD, finance, governance, administration, safety, law, medicine, and other specialists retain their subjects, Methods, evidence, and authority.

OPS.1:End

OPS.2 - Select Work-Management Views and Coordination Methods

OPS.2:0 - Use This When

Use this pattern when the same continuing Work is being called a project, process, case, workflow, queue, programme, or control loop and that choice changes coordination. Enter when one view hides a decision that another exposes: a process map may not show a permissible next action for an exceptional case, a project plan hides recurring service, a case file hides aggregate load, a queue hides commitments and subject state, or a loop diagram hides the operating account.

The first useful move is a question-to-view decision:

For decision D about subjects S at grain G, use view V and coordination Method M under conditions C; relate it to views V2... through these subject correspondences, commitments, handoffs, coexistence rules, and stop conditions.

This result need not select one permanent mode. It may choose one view, several compatible views, or no new view when the existing coordination already answers the question.

Recognition is cheap: enter when practitioners disagree about “what kind of Work this is” or cannot answer a current question from the existing view. Assurance is heavier: selected structures, direct relations, Work, Methods, planning claims, control claims, rates, authority, safety, and evidence keep their own FPF or specialist tests.

Do not use OPS.2 to classify Work into a universal natural kind, infer performed Work from a plan, select a structure by diagram appearance, or prescribe one lifecycle. If the question concerns only the identity of an already selected structure, mathematical lens, or architecture view, use A.22, C.29, or C.30.LCA directly.

OPS.2:0.1 - Working Distinctions

Name used here	Meaning
Work	Intended or performed activity under its governing FPF pattern. A management view describes or coordinates Work; it does not create another Work occurrence.
viewpoint question	The exact question a view must answer for a named user and decision, such as dates and allocation, repeatability, changing subject state, aggregate waiting, or feedback and rate separation.
Work-management mode	The selected use of one or more descriptions and coordination Methods for the current Work and questions. It is a decision result, not a Work kind or maturity stage.
project view	A description emphasizing a time-bounded undertaking, commitments, intended results, decisions, dates, WorkPlan content, allocation, dependencies, and closure conditions.
programme view	A description coordinating several projects or change commitments and their dependencies or intended contributions. The label does not create a containing System, benefit, or authority.
process view	A description emphasizing a recurring Method, inputs, results, repeated order or constraints, and control points. It does not prove that every occurrence follows the description.
case view	A description organized around a changing subject, current facts, commitments, discretionary or constrained next Work, exceptions, and closure conditions. The case is not its file.
queueing view	A description of eligible items, membership, order or service relation, waiting, arrival, departure, resource demand, and policy for one receiving question. The queue is not a board column.
control-structure view	A current FPF description of one selected control structure and its actual observation, actuation, reference, supervision, feedback, and rate-relevant relations. It is conditional, not an Operations default.
coordination Method	A reusable way of coordinating the Work under stated conditions. A view can expose what the Method needs without being that Method.
mixed-mode decision	An explicit co-use account stating subject correspondence, scope and grain, commitments, handoff or coexistence conditions, decision rules, conflicts, and stops among unlike views and Methods.

OPS.2:1 - Problem Frame

Project, process, and case management are often offered as competing descriptions of reality. Operations practice then chooses a tool or school and lets its default object model decide what exists. Yet one release operation can have a project for platform migration, a recurring process for validation, cases for field incidents, a queue for a scarce test rig, and a control view for observation and intervention at unlike rates.

These views are useful when they supply information needed by the receiving decision. They need not be isomorphic. Select each for the question it can answer and preserve correspondence where decisions cross them.

OPS.2:2 - Problem

One-mode selection loses information. A process-only account can force evolving cases through a route whose next Work depends on new facts. A case-only account can hide repeatable validation and shared capacity. A project-only account can treat continuing service as a temporary deliverable. A queue-only account can optimize waiting while breaking a commitment. A control-only account can turn observation and actuation into a complete management Method.

The opposite failure is an ungoverned hybrid: every tool and view is kept, but subjects, grains, states, and decisions disagree. Participants spend more effort reconciling records than coordinating Work.

OPS.2:3 - Forces

Force	Tension
Familiar methods	Teams can act quickly with a known project or process Method, while familiarity can hide the wrong question.
Several truths	Unlike views can all be useful, while their subjects and state claims may conflict.
Runtime discretion	Some Work can be planned, while new facts require case-responsive continuation.
Aggregate coordination	Individual cases need attention, while shared queues and resources require a population view.
Control language	Feedback and rate distinctions can change coordination, while a loop diagram can overclaim stability, safety, or authority.
Affordability	A full multi-model account is expensive, while one view may omit the next decision.

OPS.2:4 - Solution

Select views and coordination Methods from the operating questions they must answer. Preserve Work identity across views, select actual structures independently, and combine only those views whose distinct information changes the decision.

OPS.2:4.1 - Pattern-Use Unfolding

Recover the operating input. Start from the OPS.1 operating System, continuing result, commitments, subjects, units, horizon, and decision. Stop if the mode question is only a label preference.
List the viewpoint questions. Name each user, decision, subject, grain, horizon, and missing information. Separate planning, recurring execution, case continuation, aggregate waiting/capacity, and control questions.
Generate serious view candidates. Include project or programme, process, case, queueing, and control-structure views only where their questions are current. Include the incumbent as the no-change option, and a simpler view when it is a plausible alternative.
Compare fit to the current Work. Examine predictability, recurrence, subject identity, decision latency, runtime discretion, plannability, shared-resource coupling, exception frequency, evidence refresh, and authority. These are comparison prompts, not a universal scoring formula.
Select the coordination Method separately. State which reusable coordination Method is used with each view, its applicability, burden, evidence, and stop. A notation, board, model, or view does not establish a Method.
Select actual structures independently. Use A.22 when a transformation-flow, queue/resource-dependency, commitment, event, case-state, control, or other actual structure changes the decision. A mathematical graph or diagram remains a representation.
Use the control branch conditionally. When observation, decision, actuation, supervision, feedback, or rate separation changes coordination, use A.22 and C.30.LCA to identify one selected control structure and recover the needed view. Use B.2.5 only for an obtaining two-sided supervisor relation and C.27.TA, C.27, or A.3.3 for the exact rate, temporal, or dynamics claim. Stop without a control view when no control relation changes the decision.
Compose views explicitly. State subject correspondences, scope and grain, governing commitments, state correspondence, handoff or coexistence conditions, decision rights, update rules, conflicts, and stop conditions. Do not rely on a “hybrid” label.
Test with a changing case. Ask what happens when new evidence defeats the plan, a case crosses a process boundary, queue delay changes a commitment, or control evidence arrives at a different rate. Repair only the affected view or correspondence.
Return and reopen. Record selected and rejected views, coordination Methods, unresolved correspondences, next subject-account need, and one observation that reopens the decision.

OPS.2:4.2 - Record the Result

Result position	Required content
use boundary	Users, decisions, subjects, grains, horizons, and useful stop.
viewpoint questions	The planning, recurrence, case-state, aggregate waiting/capacity, control, or other exact questions that remain current.
candidate views	Incumbent (no change), serious alternatives, selection reasons, rejected uses, and missing evidence.
coordination Methods	Named Methods, applicability, burden, evidence, authority, and stops; no identity with the view or tool.
selected structures	Exact actual structures and direct relations relied on, plus representation and mathematical-lens boundaries.
mixed-mode correspondences	Subjects, grains, commitments, state correspondence, handoffs/coexistence, update and decision rules, conflicts, and stops.
control branch	Selected FPF control view and relied-on relations/rate claims, or an explicit `not current` or return result.
continuation	Inputs supplied to OPS.3/OPS.4 and an observable reopen condition.

OPS.2:4.3 - What Changes in Practice

The team stops asking whether Work “is” a project, process, or case. It asks which descriptions and coordination Methods answer each decision, then relates them through exact subjects and commitments. A view can be added, narrowed, or retired without retyping the Work or rebuilding every other view.

OPS.2:5 - Archetypal Grounding — PumpWorks Mixed Operating Views

PumpWorks-ControlServiceOps coordinates several unlike questions:

Current question	Selected view and Method contribution	Boundary
How should `FieldIncident-I73` continue after new field evidence?	Case view over the field installation, incident state, commitments, evidence, authority, and permissible next Work.	The ticket is a record; safety and product decisions retain their owners.
How is release evidence repeatedly produced and checked?	Process view of the recurring validation Method and its input/result relations.	A process description does not establish that an occurrence happened or conformed.
How is a time-bounded provider-platform migration coordinated?	Project and, when several projects are coordinated, programme views of commitments, WorkPlan content, decisions, allocations, and closure.	The plan is not performed Work, adoption, or benefit.
How is scarce rig access coordinated across eligible requests?	Queueing view over exact request membership, order/service relation, waiting, resource access, and policy.	Establish request membership, service order, and resource access for this queueing view; a board column alone does not establish them.
Which observations and interventions matter at unlike rates?	Conditional control-structure views for the product-side plant/controller/observer/supervisor relations and the operating-supervision relation.	FPF owns the generic structures and rate claims; the diagram is neither the account nor the Operations Method.

The views preserve correspondences to ReleaseCandidate-R42, FieldIncident-I73, SafetyQuestion-S19, ProviderChange-P8, the test rig, commitments, evidence results, and decisions. The incident case can request a validation-process occurrence; that occurrence can consume rig capacity; its evidence can inform the weekly release decision; a platform-migration project can change provider access. None of these relations makes the views one structure.

The product-control structure has FieldPumpInstallation-P4 as plant, FieldTelemetryObserver-O4, DeployedController-C17, and FieldModeSupervisor-S1 only where their direct relations obtain. The operating-supervision structure has ReleaseSupervisorTeam-S2 receive operating-state reports and return release, hold, rollback, or permitted-mode constraints to the operating System. The timing claims remain separate: sub-second product control, minute-to-hour field observation, daily incident triage, weekly release, and slower provider change. OPS.2 selects their use; it establishes no feedback closure, stability, safety, or authority.

Reopen the mode decision when a new subject cannot be related across views, a plan repeatedly fails after new facts, queue policy changes a commitment, a control relation becomes decisive, or maintaining one view costs more than the decision value it supplies.

OPS.2:6 - Bias-Annotation

Recurring bias	Likely drift	Repair
one-true-kind bias	Work is declared inherently project, process, or case.	Recover the question, subject, and selected view; preserve Work identity.
tool ontology bias	The tracker schema decides which objects and states exist.	Identify subjects and relations first; treat the schema as representation.
hybrid-label bias	“Hybrid” hides missing correspondences and decision rules.	State subject/grain mappings, commitments, coexistence, conflicts, and stops.
process-normality bias	Exceptions are forced back into the designed route.	Use a case view when new facts change permissible next Work.
project-temporariness bias	Continuing operation is treated as a project deliverable.	Keep the time-bounded change view separate from ongoing service Work.
loop-as-method bias	A feedback diagram becomes the whole Operations Method.	Use the conditional FPF control branch and retain the operating decision separately.

OPS.2:7 - Conformance Checklist

The decision begins with an OPS.1 operating focus and exact viewpoint questions.
Work identity is preserved across every selected view.
Project, programme, process, case, queueing, and control are selected for questions rather than declared natural Work kinds.
Coordination Methods, views, actual structures, diagrams, and tools remain distinct.
Selection considers predictability, recurrence, subject identity, decision latency, runtime discretion, plannability, and relevant coupling without pretending to use a universal score.
Every mixed-mode use states subject and grain correspondence, commitments, coexistence or handoff, update and decision rules, conflicts, and stops.
The control branch names actual participants and direct relations only where they obtain and returns rate/dynamics claims to their FPF owners.
A changed case or cross-view probe can expose a failed selection or correspondence.
Rejected views, unresolved gaps, next inputs, and a reopen condition are explicit.

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

Anti-pattern	Repair
“Everything is a process.”	Identify changing subjects and ask whether discretionary or constrained case continuation is needed.
“Every initiative is a project.”	Separate time-bounded change commitments from recurring and continuing operation.
“Case management means no process.”	Retain reusable Methods and recurring subwork while letting subject state govern permissible next Work.
“Put all work in one queue.”	Name eligibility, service/resource relation, commitment effects, and the subjects that must remain separate.
“Use one integrated model.”	Preserve non-isomorphic views and relate only the claims the decision consumes.
“The loop proves control.”	Recover actual relations and use direct rate, dynamics, evidence, safety, and assurance patterns.

OPS.2:9 - Consequences

The pattern lets an operation combine familiar management practices without letting any one practice define the ontology. It makes view debt visible: missing correspondences, duplicated state, stale mappings, and coordination cost become explicit decision inputs.

The cost is maintaining subject and state correspondence where several views are genuinely useful. Some integrations are rejected because the views answer no different question or cannot preserve identity and commitments reliably.

OPS.2:10 - Rationale

Different views earn their place by changing a decision. Project, process, case, queueing, and control descriptions foreground unlike structures, times, and questions. Treating them as views preserves their strengths and avoids a false taxonomy of Work. Explicit mixed-mode rules then make coexistence testable without requiring one universal model.

OPS.2:11 - SoTA-Echoing

Practice question	Selected current line and serious alternative	Defect overcome and governed loci	Source roles and limits	Reopen condition
Which management views should coordinate one operation when project, process, case, queueing, and control questions coexist?	The selected current line is question-relative multi-view selection with explicit subject, state, commitment, and decision correspondence. The serious alternatives are one canonical project/process/case taxonomy and an ungoverned overlay of tool views.	A single view suppresses questions it cannot answer; an ungoverned overlay produces incompatible status, identity, and authority claims. Adapt: `OPS.2:4.1` selects each view from its question, `OPS.2:4.2` records correspondence and unresolved conflicts, `OPS.2:4.3` permits local addition or retirement, and `OPS.2:5` tests coexistence. Reject: treating a view name as the Work’s ontological kind or combining views without a receiving decision.	Select each view of Work for its question, using FPF distinctions for actual structures, representations and control. CMMN, DCR, Kanban and layered-control sources address different case, workflow and control questions; compare their contributions for the views needed by the operation.	Reopen if a current integrated Method answers the unlike questions with no worse subject/state correspondence, authority clarity, repair locality, and application effort, or if repeated use changes a view’s decision contribution or the minimum correspondence rule.