#Decision-Relevant Least Action and Operational Parsimony

A.11.OP · Stable · Part A pragmatic principle pattern · Normative unless marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Part A pragmatic principle pattern Class: Prag Status: Stable Normativity: Normative unless marked informative

Plain name. Keep only work that changes a substantive choice or result, or protects a condition on which the use relies.

Primary reader. A practitioner or designer deciding whether one proposed action, step, check, record, wait, cue, tool use, or other apparatus should be mandatory.

Use this when. Use this pattern when someone proposes making an action or apparatus mandatory and a plausible question remains: does this requirement change the subject work, or does it only make the route look controlled?

#Relations

#Content

#Problem frame

Use this when. Use this pattern when someone proposes making an action or apparatus mandatory and a plausible question remains: does this requirement change the subject work, or does it only make the route look controlled?

The primary EntityOfConcern is one proposed mandatory requirement under one declared use and one substantive horizon. Action, apparatus, requirement, and horizon are ordinary working words here. This pattern introduces no generic U.Apparatus, U.Move, action kind, horizon kind, or result record.

First useful result. Return one of two short answers:

• retain the requirement for this use and horizon because it changes a named substantive branch, realizes an already selected result, or preserves a named assurance or recovery condition on which the use relies; or
• remove the requirement or leave it optional because none of those conditions changes when it is removed.

Ordinary use needs no score or separate record. Name the receiving decision, result, reliance, or recovery condition in the same sentence as the disposition.

Three recognition cases.

• A team has added a second status update before a repair decision. Every possible status leaves the same repair action, and no later user relies on the duplicate update.
• A laboratory considers a bounded probe that leaves today's setup unchanged but can determine which of two methods will be used next week.
• A release route contains both a deterministic build step that creates the selected publication and an assurance check whose evidence is consumed by the release decision.

These are one recurring problem across unlike situations: mandatory effort can be ceremonial, immediately productive, decision-relevant only later, or necessary because another use relies on the assurance or recovery condition it preserves.

What goes wrong if missed. Requirements accumulate because each sounds prudent in isolation, while their possible results change no substantive choice and produce no selected result. The opposite error removes exploration, deterministic realization, safety evidence, recovery support, or a small discriminating cue merely because it does not change the next administrative state.

What this buys. The practitioner can remove ceremony without treating the fewest steps as the goal. Useful exploration, realization work, assurance, option preservation, and recovery remain when their receiving use is named.

Not this pattern when.

• When a law, regulation, duty, permission, prohibition, safety floor, evidence rule, or gate condition is in question, use the pattern or authority that establishes that obligation. This pattern neither creates nor cancels it.
• When several already qualifying alternatives need comparison, use their direct choice, apparatus, architecture, or Method Engineering pattern.
• When the question is whether a new durable ontology value should exist, use A.11.
• When the question is how to use an already selected pattern, use E.11.PUA or E.11.PUR.
• When ongoing Work needs one next action chosen from current facts, use A.15.7.
• When an available direct-kind apparatus is already being configured for a declared use, use C.19.2 for that application question.

#Problem

Methods, workflows, reviews, and support arrangements can accumulate reads, meetings, checks, fields, records, waits, handoffs, prompts, and tool calls. Each addition can be defended by a possible future benefit. If hypothetical usefulness is enough, every requirement survives. Attention and elapsed time then move from the subject result to the route's own states and receipts.

Simple minimization fails in the other direction. A deterministic assembly step may have no rival outcome yet still create the selected result. Information may change a later policy rather than the immediate action. A safety check may confirm the expected state while supplying evidence on which release reliance depends. A recovery cue may prevent continuation from the wrong place. Counting branches, steps, documents, or minutes does not distinguish those cases.

The problem is therefore not how to minimize action in general. It is how to admit one proposed mandatory requirement only when a materially plausible difference reaches a named substantive use, without weakening the direct authority that governs the action.

#Forces

#Solution

Apply one bounded admission question before making the proposed action or apparatus mandatory.

Admission rule. An author or method designer MUST NOT make a proposed action or apparatus mandatory unless at least one materially plausible result can change a named substantive decision or branch within the declared horizon, the action realizes an already selected transformation or required subject result, or removing it changes a named assurance or recoverability condition on which the declared use relies.

Passing one branch means only that the requirement is not ceremonial for this use and horizon. It does not establish authorization, sufficiency, completion, optimality, minimum cost, safety, legal permission, or precedence.

#Name the use and nearest substantive horizon

1. Name the proposed requirement and the declared use for which mandatory status is being considered.
2. End the horizon at the nearest named substantive decision, receiving use, selected transformation result, assurance use, or recovery use that can justify the requirement.
3. Name the possible result or removal consequence that reaches that horizon. Do not use the requirement's own status, completion flag, receipt, or other administrative transition as its receiver.

The nearest substantive horizon is not necessarily the next event. It may include a later decision when the dependency from the present result to that decision is stated. It does not extend through an unnamed audit, unspecified future reuse, a merely possible receiver, or an indefinite claim that the action may be useful someday.

#Compare keeping and removing through three branches

Compare the concrete situation with and without the requirement. If one branch passes, retain the requirement at no more formality than its direct owner and named reliance need justify. If several forms pass, return their comparison to the direct choice, apparatus, architecture, or Method Engineering owner rather than inventing one scalar minimum.

If no branch passes, remove the requirement or leave it as an optional convenience. Do not preserve mandatory status merely because the action is cheap, familiar, automated, prestigious, measurable, or already present.

#Judge material plausibility through the subject claim

Materially plausible means more than logical possibility and less than certainty. The applicable subject, evidence, causal, risk, decision, or assurance pattern supplies the basis appropriate to the consequence. A low-probability result can remain material when its consequence changes exposure or the admissible policy. A large information volume is not material unless some result can change a named receiving use.

When the basis needed to distinguish branches is absent, return the missing basis or run a bounded experiment whose possible results can genuinely change the named decision. Do not convert uncertainty about usefulness into a permanent mandatory requirement.

#Return authority and claims to their direct owners

Apply this screen inside the space left by current authority. Law and regulation, E.5 Guard-Rails, B.3 assurance floors, and a direct evidence, gate, duty, or safety pattern remain controlling. If their basis or applicability is disputed, return to that authority; do not use operational parsimony as an appeal court.

A passing result also leaves downstream claims separate:

• A.3.1 and A.3.2 establish Method and MethodDescription identity;
• A.15.1 establishes dated Work, while A.15.7 selects a next action during ongoing Work;
• C.11, C.19.2, A.19, and Method Engineering compare qualifying alternatives under their own conditions;
• A.10, B.3, and the applicable gate or duty pattern establish evidence, assurance, acceptance, and authority claims; and
• E.13 repairs proxy displacement, while E.23 governs operations inside a repeated evaluated improvement loop.

The admission result supplies none of those conclusions by itself.

#Keep the result light and reopenable

For ordinary use, say:

Keep <requirement> for <declared use> until <nearest substantive horizon> because <named branch and receiving difference>.

or:

Remove or demote <requirement> for <declared use> because keeping and removing it produce the same substantive decision and result and change no relied-on assurance or recovery condition.

Create a durable claim-bearing episteme only when a named later use must cite, compare, audit, or rely on the disposition. Use an existing record kind appropriate to that use. Do not mint an OperationalParsimonyRecord or require a checklist merely to show that this pattern was consulted.

Reopen the disposition when the horizon, plausible results, selected transformation, direct duty, assurance floor, recovery reliance, or burden-bearing alternative changes.

#Keep framework layers distinct

FPF owns this cross-domain admission principle. A Method Engineering DPF may use it when designing requirements, architecture, support, trials, or practical-worth comparisons for a named Method situation; that DPF still owns those Method-specific decisions. A local practice framework may bind the principle to its own execution and assurance mechanisms; those local mechanisms neither become FPF law nor prove that the general admission condition holds.

#Archetypal Grounding

#Duplicate status update and deterministic publication build

A publication repair route asks for a second status update immediately before the repair decision. The update has the same possible values as the first one. None changes repair, stop, or publish, no receiver cites it, and removing it changes no assurance or recovery condition. The second update passes no branch, so the route removes it or leaves it as an optional convenience.

The same route runs a deterministic build after the sources and publication form have been selected. The build has no decision-changing outcome by design, but it assembles the selected sources into the required publication. It passes selected realization and remains. Its admission does not prove source acceptance, publication correctness, release, or availability; those claims retain their direct owners.

#Exploration whose value appears in a later decision

A maintenance team must choose next week between Method A and Method B for a recurring seal failure. A bounded probe performed today can return one of three observations: evidence favoring A, evidence favoring B, or an unresolved result that triggers a hold. Today's immediate action is unchanged, but every possible probe result has a named effect on the later Method-selection decision.

The probe passes the decision-changing-result branch. Its horizon ends at that named selection and its stated window, not at the probe's completion flag. If the team later shows that every possible observation leads to Method A, the probe no longer passes for that use and is removed, redesigned, or made optional.

#Assurance evidence with an unchanged operating decision

A pressure-system release check is expected to confirm the current operating decision. The release authority nevertheless relies on its evidence, and omission changes the accepted exposure for release. The check passes assurance preservation even when its most likely result leaves the operating branch unchanged.

B.3, the applicable evidence pattern, and the release authority set the assurance floor and disposition. A.11.OP only prevents the check from being dismissed as ceremony because it confirmed the expected state. A precautionary label without a named reliance, exposure change, or direct owner would not receive the same treatment.

#Recovery cue and discriminating language

After an interrupted multi-part analysis, a small cursor identifies the last closed item and the next item. Removing it can cause the practitioner to repeat completed work or resume from the wrong branch. The cue passes recovery preservation while that continuation use relies on it. If the task is short and the next item is already unambiguous, the same cursor becomes optional.

In another case, a sentence must distinguish a reusable Method from dated Work that enacted it. The distinction changes whether the practitioner repairs a description claim or a performance claim. The language passes the decision-changing-result branch for that use. The example creates no blanket exception for terminology: a distinction that changes no interpretation or action is informative at most.

#Speculative compliance without a receiver

A team proposes generating a compliance packet for possible future reuse. No law, duty, regulator, customer, gate, decision, assurance use, or recovery dependency is named. The packet therefore passes no branch and is not mandatory.

If an applicable duty or relying receiver is later established, reopen the disposition under that direct authority. The earlier speculative possibility was not evidence that the duty already existed.

#Bias-Annotation

Scope: Universal for the cross-domain admission question governed by this pattern.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The pattern changes practice before a requirement is installed. A designer names the receiving horizon and checks what keeping or removing the requirement changes. Duplicate status work becomes removable without making “less paperwork” a universal argument. Deterministic transformations remain because they produce the selected result. Exploration, assurance, recovery, and small cues remain when their delayed or relied-on consequence is explicit.

#Rationale

Operational parsimony is about relevance, not abstract minimization. The fewest-step method can be wrong when one additional action realizes the chosen result, changes a later policy, or preserves a relied-on condition. The longest method can also be wrong when its extra actions have no substantive receiver. Comparing keeping and removing one proposed requirement makes that difference visible without inventing a global cost function.

The three branches cover distinct reasons for mandatory status. Decision-changing result preserves exploration and discrimination. Selected realization preserves deterministic work. Assurance or recoverability preservation protects evidence, exposure, restart, rollback, and option value when another use relies on them. None of those reasons supplies the stronger claim governed by its direct owner.

The horizon must be substantive and bounded. A next-event horizon hides delayed information value; an indefinite horizon lets hypothetical future usefulness justify everything. The nearest named receiver is the smallest horizon that can carry the reason and the smallest reopen boundary when the use changes.

No new ontology or record is needed. The rule coordinates existing decisions, transformations, results, evidence, assurance, and recovery uses. Keeping these objects under their direct patterns preserves FPF layering while giving practitioners one discoverable admission question.

#SoTA-Echoing

#Relations

• Classified by: E.3 as one Prag principle. It primarily advances P-1 Cognitive Elegance, P-7 Pragmatic Utility, P-10 Open-Ended Evolution, and P-11 State-of-the-Art Alignment while respecting the other Pillars. It adds no custom precedence edge.
• Coordinates with, but does not specialize: A.11, which governs admission of ontology additions. Namespace adjacency makes the two parsimony questions discoverable without combining their EntitiesOfConcern.
• Coordinates with: E.11.PUA and E.11.PUR, which govern use, recommendation, coordination, and reuse after a pattern has been selected. A.11.OP asks whether an extra mandatory requirement belongs in the first place.
• Coordinates with: C.19.2, which governs bounded application and configuration of available direct-kind apparatus. Passing A.11.OP neither meets its application threshold nor chooses among configurations.
• Coordinates with: E.13 for proxy-to-value repair and E.23 for operations inside repeated evaluated improvement. Neither is the general owner of initial action admission.
• Coordinates with: A.3.1 and A.3.2 for Method and MethodDescription identity, and with A.15.7 for next-action choice during ongoing Work. A.11.OP governs design-time admission of the requirement rather than Method identity or live steering.
• Constrained by: law and regulation, E.5 Guard-Rails, B.3 assurance floors, and the direct evidence, gate, duty, safety, choice, Work, transformation, publication, and authority patterns applicable to the use.
• Consumed by: Method Engineering and other DPFs when they decide whether domain-specific requirements or support apparatus deserve mandatory status. Those frameworks retain their domain questions, architecture, evidence, and practical-worth decisions.
• May be specialized by: local practice frameworks for concrete execution and assurance. Their local arrangements remain local rather than FPF authority.

#A.11.OP:End

---

Last Updated: 2026-09-03 — this section last modified in upstream FPF commit 59c45532 (github.com/ailev/FPF)