Part III — Admit Demand and Continue Cases

OPS.5 - Admit Work and Limit Starts

OPS.5:0 - Use This When

Use this pattern when exact eligible operating demand may be explicitly started or committed now, but the operating System cannot honestly start everything that appears ready. Typical cues are “pull the next item”, “approve this case”, “the card is top priority”, “the agent is free”, “the rig has an opening”, or “we already selected it” without a current admission decision, start permission, or explicit start limit.

The first useful result is one bounded admission account:

For eligible demand D serving operating result or commitment R, under criteria and non-negotiable conditions K, explicit-start limit L, deciding authority A, configuration and horizon H, each considered item is admitted, deferred, rejected, or returned; an admitted item has effective start conditions and an authorized starter where one exists; residual demand and the next review or return remain visible.

Recognition is cheap: enter when one exact demand item needs a truthful “may enter now?” answer. Assurance is stronger: eligibility, admission, priority, permission, commitment, actual Work, result, safety, release, and service fulfilment each retain their own evidence and authority.

Do not use OPS.5 to design a queue or buffer policy, identify or exploit the current constraint, size capacity under variability, coordinate interacting structures, or make a whole-service commitment credible. Return those questions to OPS.8–OPS.13 when their results are available, or to a qualified direct source. If the current problem is continuing an already admitted case after facts changed, use OPS.6. If age, dependency, risk, or consequence may revise priority or an existing commitment, use OPS.7.

OPS.5:0.1 - Working Distinctions

Name used here	Meaning
eligible demand	An exact demand item, such as a request, need, condition, case, or candidate Work item, that may be considered for current admission. Identify the demand claim and the subject it concerns separately. Eligibility is not admission, priority, permission, commitment, or Work.
option or request	A possible demand item presented for consideration. Its presence in a list or account creates no right to admission.
admission decision	A bounded decision about whether exact demand may enter the selected current coordination account under stated criteria, limits, horizon, and authority.
admitted item	Eligible demand whose admission conditions obtain for the stated configuration and horizon. Admission permits a further start decision under its conditions; it does not establish start or result.
deferred item	Demand not admitted now, with the observation, condition, horizon, or changed fact that would make reconsideration useful.
rejected item	Demand declined for this operating use, with its reason and any receiving return that another owner can answer.
returned item	Demand for which a named missing, stale, unsupported, or externally owned condition prevents this admission decision.
start permission	An obtaining permission or authorization for the admitted matter under effective conditions. A comparison or selected answer is not permission unless the deciding System also has and exercises the required authority.
explicit-start limit	A stated bound on what may be started now for this operating use. It is not a universal WIP number, capacity model, queue policy, or constraint-buffer design.
commitment	A promise or obligation with parties, content, conditions, horizon, authority, and status. Admission can rely on or create a bounded commitment only where the relevant authority is present.
authorized starter	The System permitted to initiate the admitted Work under the effective conditions. Responsibility, capability, availability, and permission remain separate.
Work occurrence	Dated Work whose occurrence is established from performance evidence, independently of the demand-admission decision. A card move, approval, selected item, plan, agent invocation, or generated artifact does not establish that Work occurred.
residual demand	Every considered or still-relevant demand item not in the admitted set, with enough identity and disposition to avoid hidden starts or silent loss.
admission result	The dispositions, reasons, conditions, authority, horizon, starter relations, residual demand, and next review or return that make the admission decision usable.

OPS.5:1 - Problem Frame

Continuing operation usually receives more apparent demand than it can honestly start. Requests arrive through customers, incidents, clinical cases, release candidates, providers, planned changes, automated agents, and internal commitments. Each item may be valuable, urgent, visible, or technically ready while still lacking the identity, evidence, permission, access, authority, or explicit-start condition required now.

The practical problem is not merely choosing the highest-ranked item. It is deciding which exact demand may cross into current operating coordination without hiding residual demand or treating selection alone as evidence that Work occurred.

OPS.5:2 - Problem

Boards and intake systems compress unlike truth states. “Ready”, “selected”, “approved”, “assigned”, and “in progress” become interchangeable labels. A high priority is treated as permission; an available performer as authority; a scheduled slot as capacity; a generated change as started Work; and an admission decision as a fulfilled commitment.

The opposite failure keeps every item nominally open. Nothing is explicitly rejected, deferred, or returned, so the operation accumulates hidden commitments and starts. Practitioners cannot recover which demand was considered, why it did not enter, or what would justify another look.

OPS.5:3 - Forces

Force	Tension
responsiveness versus truthful starts	Delay can harm service, but premature starts create hidden Work, interruption, or unsafe continuation.
common intake versus unlike subjects	A shared account aids coordination, but incidents, patients, release candidates, provider changes, and rig requests retain different identities and conditions.
comparison versus direct rule	Several live alternatives may need choice, while mandatory or recognition-based conditions should not be converted into an artificial option contest.
local limit versus wider policy	One explicit-start bound can close the current decision without claiming a complete queue, capacity, or constraint Method.
visibility versus authority	Making demand and evidence visible helps, but neither visibility nor rank grants permission or commitment authority.
fast admission versus adequate evidence	A short-horizon answer is useful only if evidence currentness, conditions, and reopen triggers remain explicit.
focus versus residual demand	A bounded admitted set reduces active burden, but deferred, rejected, and returned demand must not disappear.

OPS.5:4 - Solution

OPS.5:4.1 - Recover only the action-changing operating inputs

Name the deciding operating System, receiving result or commitment, configuration, and horizon. Reuse matching current OPS.2, OPS.3, and OPS.4 results only where the selected coordination form, exact subjects and relations, current claims, uncertainty, permissions, commitments, or gaps can change admission. If an input is stale, mismatched, or absent, repair or return that exact blocker; do not reconstruct the whole operation by default.

OPS.5:4.2 - Name each exact demand item and its proposed use

For every item under consideration, state the demand subject, claimant or source, proposed operating result, relevant commitment, and why admission is current. Keep a request, option, candidate Work item, admitted item, commitment, start permission, and performed Work separate even when one record represents several of them.

OPS.5:4.3 - State criteria, non-negotiable conditions, and the explicit-start limit

Record the conditions that can change the admission decision. Test exact identity; relevant readiness and evidence; required authority or permission; intended receiving use; safety, legal, clinical, security, or other specialist returns; performer and access conditions; current commitments; and the capacity, resource access, bounded concurrency, or explicit-start limit that matters now.

Do not translate these into a universal score. Some conditions are mandatory, some admit qualified comparison, and some require a return to another owner.

OPS.5:4.4 - Choose only where a real choice exists

When a direct domain rule, mandatory condition, or recognition branch gives the answer, apply it and record the basis. When several live admissible alternatives genuinely require comparison, form a stable current OptionSet and comparison basis and use C.11. If the options or comparison facts are insufficient, choose a bounded probe only when it can change the decision, or return the missing condition. Do not manufacture an OptionSet merely to make admission look analytical.

OPS.5:4.5 - Give every item a usable disposition

Return each considered item as:

admitted, with reason, effective conditions and horizon, governing authority, authorized starter where established, and next review;
deferred, with the condition, observation, horizon, or changed fact that makes reconsideration useful;
rejected, with the reason and receiving return where another owner can answer the need; or
returned, with the exact missing or externally owned result, what it blocks, safe stop, and retry condition.

Keep the residual demand visible. Record no start merely because the item is admitted.

OPS.5:4.6 - Close the local decision and expose wider returns

State the admitted set, current explicit-start limit, unresolved or residual demand, next review, and the facts that reopen this admission. If the answer now depends on queue ordering, buffer design, a current constraint, capacity under variability, interacting structures, credible whole-service commitments, clinical triage, safety acceptance, release, law, finance, or another specialist result, return to that owner without filling the gap locally.

OPS.5:5 - Archetypal Grounding — Three Admission Replays

OPS.5:5.1 - PumpWorks controller service

PumpWorks-ControlServiceOps considers ReleaseCandidate-R42, FieldIncident-I73, SafetyQuestion-S19, ProviderChange-P8, and competing test-rig requests while maintaining weekly evidenced-release commitments. The current account exposes missing test T9, a safety-return gap, provider-access conflict, release authority, service consequences, and the current rig-access relation.

OPS.5 keeps the items separate. It can admit bounded incident-diagnosis Work for FieldIncident-I73 when identity, incident authority, evidence, performer, and access conditions obtain. It defers release continuation whose required T9 evidence or rig access is absent. It returns SafetyQuestion-S19 to the competent safety authority. A high rank, booked rig request, release candidate, or weekly horizon creates neither capacity, permission, Work, nor release. The first usable result is the item-by-item admission account and visible residual demand; the first honest blocker is the exact missing permission, evidence, access, or specialist return.

OPS.5:5.2 - Public-hospital emergency-care operation

One emergency-care operating function considers operating Work around exact patient and clinical-case subjects, changing observations, waiting, bed relations, service horizons, and current clinical and operating evidence. OPS.5 can return a bounded operating admission disposition only from authorized inputs. It does not turn a patient into a generic Work item or infer clinical priority from waiting age.

If consent, clinical evidence, competence, medical-safety, privacy, statutory permission, or another specialist condition is missing, the result names that blocker and its owner. Operations neither supplies treatment authority nor overrides clinical judgement. The first useful result is an authorized operating admission or an exact returned condition, not a dashboard state or automatic triage result.

OPS.5:5.3 - AI-assisted software operation

One software operation considers user issues, agent episodes, candidate changes, harness and tool access, traces, test results, human decisions, and release commitments. OPS.5 uses current context and tool capacity, bounded concurrency, integration burden, evidence needs, and established human or other authority to decide what may start.

A model score, available agent, free context window, generated patch, or scheduled episode does not by itself establish admission, permission, performed Work, or release. The result admits only the exact bounded Work whose identity, conditions, evidence, access, authority, and start limit obtain; it defers or returns the rest with retry conditions. Security, software assurance, provider capability, agenthood, and release authorization remain direct specialist returns.

OPS.5:6 - Bias-Annotation

Bias or pressure	How it distorts admission	Countermeasure
visibility and rank bias	The top visible item appears authorized and ready.	Test identity, evidence, permission, authority, and start conditions separately.
sunk-commitment pressure	Earlier planning or public promise is used to force admission.	Recover the actual commitment parties, conditions, authority, and current status.
utilization pressure	Every available person, rig, tool, or model is filled immediately.	State the bounded receiving result and explicit-start limit; preserve deliberate non-start.
automation bias	A model recommendation or generated artifact is treated as admission or Work.	Require a separate admission result, authorized starter, performance evidence, and later result evidence.
urgency leakage	Age or consequence language becomes automatic admission order.	Leave priority and commitment revision to `OPS.7`; use only the current admission criteria here.
silent-rejection pressure	Deferred or rejected demand disappears from the account.	Preserve identity, disposition, reason, retry or return, and residual demand.
source-school anchoring	A familiar board, backlog, buffer, or WIP rule supplies the whole Method.	Adopt only the bounded mechanism that changes this decision and keep its limits explicit.

OPS.5:7 - Conformance Checklist

The exact operating System, receiving result or commitment, configuration, and horizon are named.
Every considered demand item has an identity and proposed receiving use.
Eligibility, admission, priority, permission, commitment, Work, and result remain distinct.
Matching OPS.2, OPS.3, and OPS.4 inputs are reused only where action-changing and current.
Admission criteria and non-negotiable conditions include relevant evidence, authority, permissions, access, specialist returns, and currentness.
The explicit-start limit is bounded to this use and is not presented as a universal queue, capacity, or constraint policy.
C.11 is used only for several real live alternatives on a stable comparison basis.
Every item is admitted, deferred, rejected, or returned with reason, conditions, horizon, and next review or return.
The authorized starter is named only where that relation is established.
Residual demand remains visible.
Admission is not claimed as started or completed Work.
Wider Operations and specialist questions return to their direct owners.

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

Anti-pattern	Failure	Repair
top card means start	Rank substitutes for authority and permission.	Record admission, permission, starter, and start conditions separately.
everything is “in progress”	Hidden starts erase residual demand and overload the operation.	Apply an explicit-start limit and give every item a disposition.
availability implies capacity	A free slot, worker, rig, tool, or model is treated as a complete capability and access result.	Recover the exact performer, resource relation, capability, permission, and configuration.
choose-first option set	An artificial score replaces mandatory conditions or direct rules.	Use the direct branch; compare only genuine admissible alternatives.
admission by artifact	Ticket creation, assignment, plan, model output, or code generation becomes “Work started”.	Admit actual Work only from independent performance evidence.
rejection without return	Demand silently disappears or repeatedly re-enters.	Keep the reason, residual identity, owner, and retry condition.
local rule claims the system	One start limit becomes a universal WIP, queue, capacity, or constraint Method.	Bound the result and return wider policy questions.

OPS.5:9 - Consequences

The operation gains a truthful boundary between demand and current starts. Participants can see what entered, what did not, why, under whose authority, for which horizon, and what should be reviewed. Hidden starts and silent residual demand become easier to challenge.

The cost is explicit identity, evidence, conditions, authority, and disposition work. Some demand remains visibly deferred or returned rather than cosmetically “active”. This pattern does not promise optimal throughput, maximum utilization, service fulfilment, or a complete queue, capacity, or constraint design.

OPS.5:10 - Rationale

Admission is valuable because it protects the boundary between possible demand and authorized current Work. Combining it with queue design, performed Work, or service assurance would make a locally usable decision depend on much wider results and would hide exactly where permission and evidence are needed.

The four dispositions prevent the false binary “start or lose”. Direct rules remain direct, genuine alternatives can be compared, and residual demand stays available for reconsideration or specialist return. The pattern therefore closes the smallest decision that lets a continuing operation limit starts while leaving unresolved queue, constraint, capacity, interacting-structure, and whole-service questions for their own decisions.

OPS.5:11 - SoTA-Echoing

Practice question	Selected current line and serious alternative	Defect overcome and governed loci	Source roles and limits	Reopen condition
How should an operating System decide what may enter now without confusing priority, permission, commitment, and Work?	The selected line is a bounded item-by-item admission account with explicit conditions, authority, starter relation, start limit, residual demand, and review. The serious default is a ranked backlog or workflow-state transition used as permission to start.	The default hides mandatory conditions and residual demand and lets visibility or selection stand for authority and Work. Adapt: `OPS.5:4.1`–`OPS.5:4.6` reuse current inputs, separate truth states, apply direct rules or genuine comparison, and return four dispositions. Reject: universal backlog ontology, fixed WIP number, or local admission as proof of performance or service.	Current FPF `C.11` supplies bounded choice among already formed alternatives, not admission criteria or authority. The Kanban Guide supplies bounded Work-item, active-item, WIP, age, cycle-time, throughput, and explicit-policy concepts. TameFlow supplies the option-versus-committed-Work and hidden-demand concerns. Reinertsen supplies queue, delay, variability, feedback, and economic trade-off mechanisms. None supplies a universal Operations Method, start permission, or complete current capacity result.	Reopen if a stronger admission account preserves all truth states, residual demand, authority, start limits, and specialist returns with less burden, or if a source changes an action-bearing admission condition.

The selected comparison is supported by these bounded source roles.

Source line	Retained contribution	Use boundary
Current FPF `C.11`	Choice, rejection, probe, and reroute among an already formed current OptionSet.	Supplies no domain criteria, permission, commitment, performed Work, or operating result.
The Kanban Guide 2025.5	Bounded Work-item boundary, active-item management, WIP, throughput, Work-item age, cycle time, and explicit workflow policies.	Supplies no universal board, queue discipline, WIP value, service guarantee, or complete admission Method.
TameFlow sources, see the source account	Distinguish options from committed Work and expose hidden demand, commitment, interaction, financial, and human-condition concerns.	The backlog/buffer prescription and concern set are not universal kinds or comparative proof.
Reinertsen, see the source account	Queue, delay, batch, WIP, feedback, variability, and multivariable economic trade-offs.	Supplies no universal priority score, permanent optimum, local-utilization rule, authority, or Work evidence.

OPS.5:12 - Relations

OPS.2 supplies a selected coordination-form decision where that form changes admission. OPS.3 supplies exact operating subjects and direct relations. OPS.4 supplies current claims, evidence, permissions, commitments, uncertainty, and gaps. None of those results admits demand by itself.
C.11 governs comparison only when several live admissible alternatives require choice. A.10 governs evidence reliance; A.15.8 governs performance-configuration and recovery questions when they become the actual blocker.
OPS.6 may consume the applicable admission and independently supported current permission for the same matter and conditions. An admission result may carry both; admission alone establishes neither permission, Work nor progression.
OPS.7 separately governs current priority or bounded commitment revision. OPS.8–OPS.13 retain queue, buffer, constraint, capacity, interacting-structure, and wider commitment questions.
Clinical, safety, legal, privacy, security, finance, product release, capability, and other specialist practices retain their subjects, evidence, permission, authority, and conclusions.
Pattern order is not Work order. Practitioners may enter OPS.5 directly when matching current inputs already exist, repeat it as demand changes, or stop after its result.

OPS.5:End

OPS.6 - Continue Cases and Handle Exceptions

OPS.6:0 - Use This When

Use this pattern during one admitted continuing case when current facts, an exception, or a changed condition makes the standard next action uncertain. Typical cues are “the normal route no longer fits”, “the ticket moved but nothing changed”, “the model recommends a fix”, “we are waiting for one more result”, or “who may act now?” while the case subject, permission, performer, evidence, and next permissible Work are unclear.

The first useful result has one of two forms:

Progression: for case subject S in qualified state Q at configuration and horizon H, matching permission P and domain Method M support next Work W by responsible performer R, with stop or fallback F and expected evidence E; after independently supported performance, report the progressed state Q' and its evidence to the participant responsible for the next operating decision under return conditions N.

Blocker: condition K is missing, stale, contradicted, unauthorized, unsafe, unsupported, or unavailable; owner or source O must supply the bounded result; safe fallback or stop is F; retry when T obtains.

Recognition is cheap: enter when participants cannot choose or execute the next permissible Work in an admitted case from the current facts. Assurance is stronger: selected action, permission, responsible performer, actual Work, resulting evidence, and progressed case state each require separate support.

Do not use OPS.6 to design one universal workflow or case lifecycle, reconstruct a reusable Method from event data, infer progress from a ticket, plan, model, trace, or record update, or revise priority merely because the case is old. Use A.15.7 for the general situation-responsive next-action Method, A.3.1.MR when reusable Method recovery from several performances is the actual question, and OPS.7 when temporal or consequence evidence can change priority or an existing commitment.

OPS.6:0.1 - Working Distinctions

Name used here	Meaning
case	One bounded continuing Work situation organized around an exact subject, state, commitments, evidence, authority, and permissible next Work. It is not its file, ticket, queue position, or every Work item within it.
case subject	The patient, incident, user issue, release candidate, service relation, request, physical item, or other exact subject around which continuation is being coordinated.
case-state claim	A qualified claim about the case subject and relevant relations at a stated time or horizon. It changes only from adequate evidence.
exception	A fact or condition for which the standard continuation branch is absent, contradicted, no longer adequate, or requires bounded choice or return. It is not automatically an error or rare event.
matching admission and permission	The applicable case admission and independently supported current permission for the same matter, effective conditions, configuration, and horizon. A valid `OPS.5` result may carry both; admission alone is not permission.
deciding System	The System authorized to select or confirm the next permissible Work. It may differ from the responsible performer.
responsible performer	The System assigned and capable for the selected Work under its conditions. Assignment, capability, permission, authority, and performance remain distinct.
next permissible Work	The exact Work that may occur next under the applicable domain Method, permission, obligations, evidence, and stop conditions. A task description or tool call alone does not show that this Work was performed.
action choice	A selected next Work, probe, fallback, stop, or return. Choice does not perform the Work or progress the case.
Work occurrence	Dated performance admitted from direct evidence under the relevant configuration. Intention, assignment, invocation, trace presence, or artifact creation does not establish it alone.
evidence expected from performance	The observations, produced results, or records needed to judge what occurred. State the claim each supports, including any claim of a changed subject state or a failure.
record update	A change to a ticket, case file, plan, model, trace, database, or dashboard. It may carry evidence but is not the case-state change by itself.
unmet condition	The exact missing, stale, contradicted, unauthorized, unsafe, unsupported, or unavailable condition that prevents a truthful next action or progressed state, together with its return or stop.
progression result	Either an evidenced progressed case state with its next return, or an unmet-condition return with owner, fallback or stop, and retry condition.

OPS.6:1 - Problem Frame

Continuing cases do not simply advance because a standard sequence exists. New observations, dependency failures, changed permissions, resource relations, specialist decisions, or unexpected outcomes can make yesterday’s next action unsafe, impossible, or irrelevant. The operation still needs a bounded way to continue without replacing the applicable clinical, engineering, legal, safety, security, or other domain Method.

The practical problem is to select the next permissible Work from the current situation and then admit progression only after performance and evidence, while returning exact blockers rather than fabricating a state transition.

OPS.6:2 - Problem

Workflow systems encourage a false equation: transition selected equals Work performed equals case progressed. A case-file state, agent loop, plan update, model recommendation, or “done” ticket appears to settle the case even when no authorized performer acted or the resulting subject state is unknown.

The opposite failure treats every exception as improvisation. Practitioners bypass mandatory domain branches, create an ungoverned OptionSet, or keep analyzing without a responsible performer, stop, evidence expectation, or return. Cases then drift between records while obligations and commitments remain unresolved.

OPS.6:3 - Forces

Force	Tension
responsiveness versus currentness	Cases need timely continuation, but stale facts or permission can make the selected action inapplicable or harmful.
domain Method versus local exception	The applicable Method constrains permissible Work, yet current facts may require recognition, adaptation, comparison, probe, or return.
chooser versus performer	The System that decides may not perform; collapsing them hides assignment, capability, permission, and responsibility.
action versus evidence	Selecting a good action is useful, but it does not show that Work occurred or the case changed.
recordability versus subject truth	Files and transitions support coordination, but they represent rather than constitute the case subject and state.
automation speed versus authority	Automated episodes can run quickly, but tool access and output do not establish permission, software assurance, release, or accountable continuation.
progress pressure versus honest blocker	A visible “next state” is attractive, while naming an unmet condition may be the only truthful result.

OPS.6:4 - Solution

OPS.6:4.1 - Confirm the case and matching permission

Name the exact case subject, current configuration and horizon, and the demand or commitment being served. Recover the applicable admission and the required current permission for the same matter and conditions. A valid OPS.5 result may carry both; admission by itself does not establish permission. If the required permission is absent, expired, or contradicted, return that blocker to the authority or source that can resolve it; do not select Work or claim progression under a merely similar item, earlier approval, queue rank, or general mandate.

OPS.6:4.2 - Refresh the action-changing situation

Recover the current qualified case state, applicable domain Method, obligations and operating commitments, action-changing evidence and its currentness, relevant permissions and authority, and the condition that made continuation uncertain. Follow only the reach that can change the next action; unaffected case claims remain reusable under their conditions.

OPS.6:4.3 - Separate decision, performance, records, and state

Name the deciding System, responsible performer, required permission or authority, available actions, actual Work to be performed, records used or changed, and the state claims the result may support. Do not infer one relation from another. If performer capability, assignment, access, permission, or authority is missing, return that exact condition.

OPS.6:4.4 - Use the least elaborate adequate steering branch

Apply the direct mandatory branch when a current rule and facts determine the next permissible Work. Use recognition when one current situation clearly matches a governed action. Adapt within the applicable domain Method when a bounded variation is authorized. Use C.11 only when several admissible live actions genuinely require comparison. Select a bounded probe only when its expected information can change the decision. If no permissible action exists, generate candidates through the owning practice or return the missing result instead of improvising an ungoverned action.

OPS.6:4.5 - Specify the executable continuation contract

State the selected next Work, responsible performer, permission and effective conditions, stop or fallback, expected evidence, and the return to continuing operation. Name the observable change that would invalidate the action and require refresh. An existing plan, instruction, prompt, ticket-transition record, or model recommendation can carry this contract if it states these terms and identifies the required authorization.

OPS.6:4.6 - Admit performance and update state separately

After the Work, recover direct performance evidence, the changed subject or result, failures and limits, and the claim each observation supports. Update the case-state claim only when the relevant Work and resulting evidence are independently adequate. If Work did not occur or evidence is insufficient, retain the earlier state claim under its stated limits and return the unmet condition. Never use a record update, successful invocation, generated artifact, or selected action as automatic progression evidence.

OPS.6:4.7 - Return one usable result

Return either:

an evidenced progressed case state, its evidence and limits, fulfilled or still-open obligations, and next return; or
the unmet condition, direct owner or source of the needed result, safe fallback or stop, and exact retry condition.

State what remains outside: priority or commitment revision, queue and capacity policy, specialist judgement, release, safety, security, clinical outcome, legal permission, and other direct results.

OPS.6:5 - Archetypal Grounding — Three Continuing-Case Replays

OPS.6:5.1 - PumpWorks field incident

FieldIncident-I73 is an admitted continuing case under the current incident Method. The operation refreshes incident impact, deployed-controller and telemetry correspondence, missing test T9, rig access, provider conditions, safety return, release authority, and service commitments. The incident chooser, responsible diagnostic or validation performer, release and safety authorities, candidate Work, records, and case state remain distinct.

If current permission and rig access support a bounded diagnostic replay, OPS.6 states that Work, performer, stop, fallback, and expected telemetry or test evidence. Report case progression only after the Work and evidence support a changed incident claim. If T9, rig access, safety return, provider permission, or current telemetry is absent, the result names that unmet condition and returns to its owner. A ticket move, agent run, recommendation, or code change does not by itself establish incident progression or release.

OPS.6:5.2 - Public-hospital clinical case

One admitted clinical case continues from the exact patient and clinical-case subjects, current observations, applicable clinical and operating Methods, authorized practitioners, bed and resource relations, service obligations, and current consent, privacy, safety, and statutory conditions. A qualified clinical System retains medical decisions.

OPS.6 can state the next authorized clinical or operating Work, responsible performer, stop or fallback, and evidence needed before the case-state claim changes. Missing consent, clinical evidence, bed relation, competence, medical-safety return, or statutory permission remains an unmet condition, not an Operations workaround. A record closure, bed-board move, or elapsed wait does not establish treatment, patient change, or clinical resolution.

OPS.6:5.3 - AI-assisted user issue

An admitted user issue encounters a changed trace, tool result, provider condition, model input, candidate change, or harness state. The operation refreshes evidence and applies the software domain Method and current established authority. It distinguishes the human or other deciding System, the responsible performer, agent episode, tool invocation, candidate change, test evidence, issue record, and release decision.

The continuation contract may authorize one bounded diagnostic, test, or repair Work with context and tool limits, stop, fallback, evidence expectation, and human return. Report issue or candidate progression only after performance evidence supports it. A successful episode, green local test, visible trace, automated loop, or generated patch does not by itself establish issue progression, an integrated change, software assurance, a security result, or release permission.

OPS.6:6 - Bias-Annotation

Bias or pressure	How it distorts continuation	Countermeasure
workflow-state bias	A configured transition becomes the case truth.	Recover the exact case subject, performance evidence, and qualified state separately.
action bias	Selecting any next step feels better than returning a blocker.	Use direct mandatory and recognition branches first; return when no permissible action exists.
automation bias	A successful agent episode or model output is treated as progress.	Separate invocation, Work, artifact, evidence, integration, and case-state claims.
plan-completion bias	Updating a plan or checklist appears to satisfy the obligation.	Name the actual Work, responsible performer, result, and evidence expected.
stale-permission bias	Earlier permission is reused after conditions changed.	Match matter, conditions, configuration, horizon, and authority before selection.
expert-shadowing bias	Operations quietly substitutes for clinical, safety, legal, or engineering judgement.	Return the bounded specialist result and keep the receiving coordination decision local.
exception novelty bias	Every surprising event is treated as unprecedented improvisation.	Reuse the applicable domain Method and choose the least elaborate adequate branch.

OPS.6:7 - Conformance Checklist

The exact case subject, configuration, horizon, and served demand or commitment are named.
The required current permission is supported for the same matter and conditions; admission alone is not treated as that permission.
Current case state, domain Method, obligations, commitments, evidence, and exception are recovered.
The deciding System, responsible performer, permission, capability, assignment, and authority remain distinct.
Available actions, selected action, actual Work, records, evidence, and state claims remain distinct.
Direct mandatory or recognition branches are used when adequate.
C.11 is used only when several admissible live actions genuinely require comparison.
The continuation contract names Work, performer, conditions, stop or fallback, expected evidence, refresh, and return.
Case progression is reported only after independently supported Work and adequate resulting evidence.
A plan, ticket, model output, episode, trace, or record update is not treated as progress by itself.
The result is either evidenced progression or an exact unmet-condition return with owner, fallback or stop, and retry.
Specialist and wider Operations results remain with their owners.

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

Anti-pattern	Failure	Repair
workflow transition equals progress	A representation substitutes for changed case state.	Require independently supported Work and resulting evidence.
selected action equals Work	A choice or instruction becomes a performance claim.	Name performer and admit the dated Work separately.
agent ran, therefore case advanced	Invocation and output hide authority, integration, and subject evidence.	Preserve episode, Work, artifact, test, integration, decision, and state distinctions.
generic exception handler	One fallback overrides domain Methods and specialist returns.	Recover the applicable Method and exact unmet condition.
chooser-performer collapse	Decision authority, assignment, capability, and performance become one relation.	Name and support each relation independently.
stale authorization carryover	Permission survives changed conditions by default.	Revalidate exact matter, configuration, horizon, and effective conditions.
endless analysis	No responsible performer, stop, evidence expectation, or return is stated.	Produce the executable continuation contract or a blocker return.

OPS.6:9 - Consequences

The operation gains a defensible continuation move for exceptional and changing cases. Practitioners can tell what may happen next, who should perform it, what evidence will count, when to stop, and whether the case truly progressed or remains blocked.

The cost is that visible motion no longer counts as progress by default. In some cases, the account cannot yet report progression while an unmet condition is returned. The pattern does not promise a universal workflow, automated resolution, clinical or engineering correctness, release, service fulfilment, or evidence that the selected Method is generally effective.

OPS.6:10 - Rationale

Case continuation sits between permission and evidence. If it collapses into admission, selection appears to perform Work. If it collapses into priority or commitment management, elapsed time or consequence pressure can bypass the applicable domain Method. Keeping the continuation contract and the later state update separate makes exceptions usable without inventing a lifecycle.

The two-result form is deliberate. An exact unmet condition with owner, safe fallback, and retry can be the complete useful Operations result. It prevents administrative state changes from hiding missing permission, capability, evidence, or specialist conclusions.

OPS.6:11 - SoTA-Echoing

Practice question	Selected current line and serious alternative	Defect overcome and governed loci	Source roles and limits	Reopen condition
How should an admitted continuing case choose and evidence its next permissible Work when facts or exceptions change?	The selected line is situation-responsive steering inside the applicable domain Method, with separate permission, chooser, performer, Work, evidence, state update, stop, and return. The serious default is a workflow, case-plan, ticket, or automated loop transition used as the progression result.	The default confuses representation with subject state and choice with performance. Adapt: `OPS.6:4.1`–`OPS.6:4.7` confirm permission, refresh action-changing facts, choose the least elaborate branch, specify performance, and admit state change only from evidence. Reject: one universal case lifecycle, record-to-Method inference, or agent output as progress.	Current FPF `A.15.7` supplies the general next-action steering Method and `C.11` bounded choice. CMMN contributes discretionary case planning and state representation; DCR contributes condition, response, inclusion, exclusion, marking, execution, and acceptance distinctions. DEMO contributes bounded commitment, coordination, and responsibility distinctions. DORA, harness, and loop sources contribute short-horizon evidence, bounded concurrency, traceable episodes, stops, integration burden, and human continuation. None supplies the case’s domain state, authority, Work, progression evidence, release, or universal Operations Method.	Reopen if a stronger continuation account preserves the same permission, domain-Method, performer, performance, evidence, state, blocker, and return boundaries with less burden, or if a source changes the permissible-action or evidence contract.