Operationalization, executability, automation, and autonomy — revised exploration

Status: a workshop investigation, not adopted technical vocabulary, empirical proof, or a system change. Revision: 2026-10-31, responding to the operator's objections that the first account confused generalization with operationalization, treated automation and autonomy too similarly, and did not check source ingestability. Repository starting point: main at d19065b3aef33ffca92fa2f72f5203251fcae3b0. Literature access was checked on 2026-10-31. Second revision: 2026-10-31, after the merge of the draft, a review of it, and the ingestion of five candidate sources. The review found that the draft restated the operator's directives as findings, misdescribed the existing actionable-methodology relation, and introduced five workshop-local coordinates without saying which are new concepts. Section 6 and the amended disposition answer those points with the ingested sources.

Central result

Operationalization is relative to a defined task T (including its application area) and an executor E in an operating setting S. It is not an intrinsic property of a text. A task definition specifies what is to be accomplished and where its validity is being claimed; operationalization asks how existing knowledge can guide E in accomplishing that task. What a trained researcher can use immediately may need adaptation for a novice, an LLM agent, or a deterministic interpreter. Every claim that something is operational must state the task, application area, executor, resources/authority, and adequacy criterion.

There are more than two possible transformations of a methodology; moreover, properties of the methodology must not be confused with properties of an executor, its runtime, or a particular execution.

Generality (outside operationalization): which additional tasks or application areas a theory or method can adequately guide. This may be researched or expanded, but doing so changes the knowledge's claimed scope or the task specification rather than being a constituent operation of operationalizing a given task.

Constraining: which readings, choices, or responses the method permits or prefers for a named consumer.

Methodological coverage (or operational completeness): which consequential tasks and decisions in applying the method have some usable guidance, including how to recognize its applicability, obtain information, choose the next operation, deal with exceptions, and stop. Guidance can specify a decision interface or an approach for obtaining evidence without settling its answer. It is not necessary for every choice to have a fixed answer. Methodological closure, already defined in Commonplace, is stronger: it concerns whether the retained method settles consequential decisions, not merely whether it supplies useful guidance for them. Coverage is therefore closure without the settling condition. Treat it as a diagnostic reading of the existing term, not as a candidate term of its own.

Operational integration: whether guidance reaches the relevant executor at the relevant time, with the requisite tools, state, permissions, feedback, invocation and binding authority. Integration changes the configured system; it need not alter the methodology's content or range of validity.

Situated executability: whether the specified executor and environment can actually perform the required work to an identified standard. This is a relation, not a textual genre and not a single successful trace. It is not a new predicate. It is the existing actionable relation, which now carries the task as its fifth element after this workshop's extraction. Section 2 states the correction.

These are diagnostic coordinates rather than scalar scores or a complete axiomatization. They do not all belong inside operationalization. Generality belongs to the knowledge's scope (or to changing task definition); automation, autonomy and warranted reliability characterize the configured executor and outcome. Operationalizing for a fixed task may constrain local choices, fill in guidance and integrate resources without claiming that the method now applies in more domains. An accidentally discovered wider application is a possible research result, not part of operationalization by definition. Distinguish the task's intended domain, what the source knowledge justifies, and what E actually handles successfully.

Operationalization is provisionally the activity of making knowledge K usable for task T by executor E under a declared operating setting S. It may produce an artifact or an operating arrangement, and it may leave substantial choices to E. The task definition supplies the application area, goal, success/stop conditions and binding boundaries; these are inputs to the operation, not scope to be enlarged by it. There is no requirement that operationalization maximize detail or constrain all choices. Generalization is a separate effort to establish how K or an existing method carries over to other tasks or applications.

There is a potential linguistic double use: a theory can be made action-guiding as a methodology for T, and an existing methodology can be made operational as a skill for the same or a narrower T and E. Both are instances of the same task-relative operation, not necessarily different definitions of 'operationalization' or mandatory successive transformations. Simply granting tools, delivering an existing instruction, or preserving runtime state can also improve the task-facing operating arrangement without deriving another methodological artifact.

Commonplace already has a narrow artifact-lineage convention, operationalized-from, in ADR 054: a methodology-to-procedure pairing where ordering, defaults, or stopping conditions are added. Do not silently broaden that adopted relation to all task-relative operationalization, especially theory-to-method work or deployment of existing artifacts. The conceptual use can be broader while its formal lineage label remains narrow pending a separate decision.

0. Task definition fixes application; operationalization makes knowledge usable for the task

Task definition and operationalization are separate operations. A task definition T supplies the application area (target/problem class), objective, success criterion, and binding scope and authority conditions. It may be a specific case ('assess this empirical claim') or a family ('review the causal claims in this class of papers'). It need not be a complete plan, and an open-ended task can state how its scope may be revised when new evidence appears.

Operationalization takes T as a given and asks how knowledge K can guide executor E, with competence and tooling S, to perform T. Its output may be a task-facing methodology, an interpreted checklist/skill, a code component, a hybrid arrangement, or no new artifact when E already knows enough. Success is relative: the arrangement improves or enables E's appropriate task-guided decisions, not merely produces more words. It does not establish generality beyond the application area specified by T or guarantee task success.

A working relation, not a formal Commonplace definition, is:

operationalize(K, T, E, S) → task-facing method or operating arrangement A

where T fixes the evaluated application, E and S supply actual competence and action possibilities, and A is judged by whether it makes K usable to guide T. Neither the output type nor the number of steps is fixed.

The operationalism ingest adds three conditions to this relation. They come from the discipline that owns the word, so they are transfers by analogy, not established results.

1. A is partial. Operationalizing K for T and E selects which operations and indicators count as applying K for this purpose. Part of K stays outside A. That residue is what A can be checked against. An account in which A exhausts K cannot say when operationalization went wrong (Gillies' validity argument).
2. "Executable by E" names a typed range of operations. If the range includes open-ended judgment, the relation rules nothing out. If it includes only codified steps, it collapses into codification. This is Margenau's dilemma carried over to executors. The workshop has not yet typed that range; the cases in section 6 are the material for doing so.
3. A is an indicator hypothesis. Following Bunge, treat "these operations serve K for T by E" as a fallible claim open to test, not a definition. The Church–Turing ingest records the same status for the thesis itself: Turing placed it between a theorem and a definition, and Post objected that calling it a definition hides the need for continual verification.

Condition 3 also settles how to read the "central result" above: it is a tentative identification, to be tested against cases, not a stipulation.

Two examples with the same operation:

Starting knowledge K	Fixed task T and executor E	Possible result A
A Popperian explanatory account of conjecture and criticism	T: critically assess claims in a research article; E: research-experienced human	A methodology explaining how to form criticisms and seek discriminating evidence; perhaps no detailed checklist
Existing conjectural-criticism methodology	Same task; E: LLM-based Commonplace agent with bounded context and tools	A selected skill, available source references, authority and stop conditions, and relevant tool access; only the missing pieces need to be supplied

The first is often described as theory → methodology; the second as methodology → procedure or operating arrangement. They share the functional test makes K usable for T by E. In a different project a methodology might not derive from one articulated theory at all. The actionable-methodology definition classifies methodologies by the guidance they supply, not by their ancestry, and the two-layer account explicitly allows methodology-native content.

Where generalization belongs: after developing A for T, one can conjecture that K or A works for a broader task T'. Establishing that claim requires new reasoning or evidence about the expanded application area. The act of extending T to T' is a task-definition or method-scope revision. Operationalizing for T' is a further task-relative operation. If operationalization for T unexpectedly discovers a general technique, retaining and testing that conjecture is separate from completing T. The same method may be operational for E on T but not on T', even if the theory's principles remain applicable.

Important boundary case: operationalizing K for T can reveal that T is infeasible, inconsistent, or under-specified. This is useful feedback to task definition, not license for the operator or agent to silently broaden or replace T. Return the issue to whoever owns task selection, or revise T through an authorized decision. The task can authorize scope discovery as part of its objective; in that case the rules for choosing a new application are part of T rather than an accidental generalization during execution.

Other boundaries: constraining choices, supplying a richer method, codifying a local rule and integrating a workflow are possible means of operationalizing for T. They are not definitions of operationalization. Automation is subsequently about which task functions the configured system performs, and decision autonomy about what choices E may make. An operationalized arrangement may remain entirely human-executed.

Provenance versus situated use: operationalized-from in ADR 054 remains the authorized methodology→procedure lineage claim, not a generic marker that K has been made operational for T/E. A procedure can satisfy that lineage convention but be unsuitable for E. An unchanged methodology can be directly usable by E without another derivative. No automatic regress follows from the fact that a methodology can itself operationalize a theory.

1. From descriptions to situated action

A description reports how work occurred; an explanatory theory proposes why. A methodology supplies an intervention-relevant mapping: which kind of action, comparison, rejection, or evaluation is favored in represented conditions. An instruction like 'critically assess the causal claim' can be a thin method when a proficient actor reconstructs appropriate tests; it is not an exhaustive plan.

Given a specified task T, inspect the specific barrier to E using K instead of assuming that more detailed steps are the missing ingredient. Changing the problem domain is a separate task-definition/generalization decision, not a default operationalization move:

Potential gap	Candidate intervention	Property principally affected
The method does not cover T's application area	Return a gap to task/method choice; separately propose revising T or researching generalization	Outside operationalization for the fixed T
Multiple plausible interpretations cause wrong choices	Add purpose, disambiguation, exclusions or examples	Constraining
The methodology does not address how to handle missing evidence or exceptions	Add decision criteria, evidence-gathering, fallback or stop rules	Methodological coverage
The model knows the method but does not select it	Select/routinely activate a coherent method, perhaps via a short cue	Activation, not necessarily more content
The operator cannot access the target or tools	Provide resources, permissions or a different execution channel	Situated executability, not theory generality
Work loses its position across context windows	Retain state, recover checkpoints, arrange subsequent calls	Operational integration and horizon
A deterministic check is cheap and stable	Commit the local predicate to code	Codification, local reliability
The evaluator cannot tell when the work is wrong	Improve evidence, testing, oracle discrimination and recovery	Warrant of outcomes
A person still performs an internal function	Transfer the specific function to computation	Automation coverage
The agent has no authority to choose a method or initiate a branch	Deliberately delegate authority and specify bounds	Decision autonomy; perhaps greater unattended scope

A broadly general methodology might be unavailable at the point of need for T. A well-integrated task procedure may be narrowly applicable by design. A capable executor may perform judgments never prescribed by the method. These cases falsify a one-directional scale of 'more operational'.

No necessary monotonicity: additional operational guidance may lower performance by prescribing a method before relevant evidence appears, forcing premature stopping, overloading context, or requiring a model to resolve contradictory constraints. Commonplace's author–executor determinability rule addresses this precise risk. A stronger artifact may fix governing intent and leave more means open; this combines stronger appropriate constraints with more contingent freedom.

2. Executability and the actor-relative boundary

For a task definition T (including its application area, objective, success conditions and scope), method M, executor E, supported operations O, target/environment S, delegated authority A, and resource horizon H, the useful question is: can that arrangement execute T using M adequately on the cases T admits? There is no reason the answer must be invariant between a trained human, weaker LLM, stronger LLM or code engine.

Three levels of evidence differ:

1. Can be attempted: the actor can interpret the method and has a way to act.
2. Can complete a specified task: the actor has the necessary operations, state, competence, permission and control to reach an outcome in a declared setting. Commonplace's existing actionable methodology already covers most of this level, not only level 1: its four elements require an operator that can follow the mapping, available operations with the needed access, resources and authority, and a target those operations reach. The first draft of this workshop understated that. What the existing relation did not carry was an explicit task with an objective and a success criterion over admitted cases. That is the only addition this workshop made at level 2, and it is now in the definition.
3. Works adequately across a domain/horizon: observed results satisfy an acceptance standard under representative variation, including exceptions, not just one successful demonstration.

A trace proves an execution occurred. It does not show fidelity to the method (the actor may import its own method), goal success (the method may be wrong), repeatability (inputs and environment may differ), or generally reliable execution. These are separate claims.

Human algorithm counterexample: pencil-and-paper long division is an exact effective procedure for a properly trained human. It does not become executable only when translated into a computer program. The classical effective-procedure sense from computability theory is restricted to mechanical steps requiring no ingenuity; it is not the broad sense of a judgment-heavy method being executable by a capable LLM.

Human checklist counterexample: a checklist can be made operational for a team through prompts, roles and timing while remaining manually performed. Making such a method actionable neither supplies an LLM with sensorimotor competence nor gives it clinical or legal authority.

Agent research counterexample: a research skill can be executed by an LLM even while it requires unanticipated judgments, choice of sources and criticism. Computational action can use natural language; there is no necessary crossing to symbolic code.

3. Automation is not autonomy

The prior account conflated 'who does the work' with 'who is free to direct it'. Their distinction must be made explicit.

Automation is an allocation of task functions to machinery/computation. It asks which operations otherwise performed manually are executed by the system. Its unit can be information acquisition, analysis, decision proposal or execution. An automated function may be highly prescribed and lack discretion. A partially automated end-to-end process can still include manual approval, diagnosis, data entry or recovery.

Decision autonomy is discretion and authority over consequential choices within delegated limits. It asks who selects goals/subgoals, methods, alternatives, exceptions, and authorized external actions, and whether the actor can revise its course on newly encountered evidence. Autonomy need not mean permission to do anything; meaningful bounded delegation is still autonomy. Decision autonomy can coexist with a mandatory human authorization gate outside the agent's scope.

Unattended continuity is another property, often associated with autonomy in ordinary speech: can the workflow run through the declared functions and horizon without requiring a fresh human production decision? Commonplace's existing computational closure addresses this property cleanly. A script can be computationally closed for invoice calculation but have almost no discretion to reconsider its procedure. Neither computational closure nor discretion establishes warranted outcome quality.

Example	Automation of scoped functions	Decision autonomy	Unattended continuity
Fixed batch script calculates payroll	Full for specified arithmetic	Very low; policy and means fixed	Yes, for the bounded batch when inputs are supplied
Agent independently proposes and revises a research strategy; human gathers sources and approves publication	Partial (planning/analysis)	Substantial in planning, limited in external action	No, for the whole task
Agent drafts code and runs tests; human must decide merge	High for production steps	Substantial within assigned design scope, no merge authority	No, if merge is required for completion
Agent chooses methods, fetches sources, evaluates, commits within standing authorization, including recovery	Potentially full for its declared task	High but bounded	Potentially yes if all required functions are computationally supplied

These examples do not define a universal numeric measure. A function allocation is not commensurable across arbitrary systems, as autonomy measurement explains. External user requirements at task commissioning are different from a human supplying run-time design or repair decisions. Decide which are outside the evaluated production boundary before measuring its closure. A human approval step essential to an in-scope completed artifact cannot be hidden as external 'feedback'.

Can operationalization make a methodology fully automatable with LLMs?

Executor-relative operationalization is neither logically sufficient nor always necessary for fully automated LLM task performance. It can increase the possibility and feasibility of that performance. A methodology may already be directly usable by one LLM but not another; matching its instructions to E does not create missing competence, permissions or outcome verification.

1. The model may already know the method and automatically do the relevant work from a broad objective without any newly retained operationalization. This is automation without explicit method extraction; it remains vulnerable to wrong method selection and opaque model competence.
2. A written methodology could fully guide a competent human but still be impossible or untrustworthy for an LLM in the same setting because it lacks tools, perception, context, substantive skill, or authority. Completeness for the human is not completeness for the model.
3. A model can autonomously supply consequential decisions not settled by the method from learned competence and situated evidence. Thus methodological closure is not necessary for computational closure. But computationally completing the task once does not imply reliable or warranted completion.
4. A narrow fully automated task can be accomplished with little decision autonomy (a deterministic calculator). A highly autonomous agent can still depend on a person for in-scope execution or admission. These are the opposite counterexamples to treating the two as one dimension.
5. An LLM system may be able to execute a whole task only for an explicitly bounded input domain, authority envelope and horizon. A policy of refusing or escalating exceptions is an appropriate safety behavior but does not count as independently completing the escalated cases. The full automation claim must either exclude those cases in advance, or admit that coverage is partial.

A task is 'fully automated' only relative to a fixed task boundary and completion criterion, when every production function necessary to complete its admitted cases is computational, including selection and evaluation if they are internal to the task. Its goals, authorization envelope and model may be human supplied initially. If autonomous task choice or revision of the operating rules is in scope, that is a larger task and demands a larger test.

This separates three propositions: the method is operable by this system; the system can complete the whole task unattended; the results are adequately trustworthy. They require different evidence.

4. Revised architectural account: several independent changes, not one progression

The earlier chain 'knowledge → selection → execution → evaluation → retention' confused logical functions with a developmental trajectory. A fixed task definition T gives the application area and evaluation boundary; operationalization concerns making K usable for T by E; generalizing to T' is another project. All those functions may exist even for a human paper-and-pencil system; the architecture can change any one of them, in different directions.

A better analytical map is:

Layer of question	Variable	Example of progress without codifying more
Knowledge and task design, outside operationalization for fixed T	Generality/domain of applicability	Research whether criticism principles also work for adversarial evidence; define and test T'
Method itself	Semantic commitments/constraints	Preserve binding provenance but leave evidence-gathering tactics open
Method itself	How much application logic is addressed/settled	Add a way to seek discriminating evidence, without preselecting its outcome
Task-relative operationalization	Derive prescriptions from knowledge K for T and E	Work an epistemic principle into a strategy for criticizing claims of the class specified by T
Task-relative operationalization	Make an existing method usable for T and E	Derive an LLM skill only if E needs it; otherwise supply missing resources or use the method directly
Method use	Selection, activation and authority	Route an existing method and verify that it governs the relevant decision
Operational environment	Tools, state, checkpoints, feedback	Enable an unchanged method to be used over longer tasks
Actor capability	What E can infer and decide when the method falls silent	A stronger model handles new cases through its learned knowledge
Labor allocation	What work computation performs	Transfer source synthesis or experiment design from human to LLM
Delegated control	How much discretion/initiative/authority computation has	Let the model select next probes inside an approved envelope
Continuity	Which required functions can run without new human intervention	Replace recurring human troubleshooting with bounded recovery
Evaluation	Scope of justified trust	Better independent checks, not merely stronger confidence claims

Important pairwise counterexamples:

• Generality without operational integration: a principled method applies in theory to more domains but is never retrieved or routed.
• Integration without generality: the exact same research method can act on an existing case after the agent receives source access.
• Constraining plus generality: adding a clear applicability test excludes wrong uses while improving successful use across new classes of cases.
• Operational completeness without methodological closure: a method says to choose tests by their expected discriminatory value; it prescribes a procedure for choosing without predetermining every test.
• High automation, low discretion: fixed rule calculates and files a result under preapproved conditions.
• High discretion, low task automation: an agent chooses a research plan while people collect samples and approve final action.
• Full continuity, poor warrant: unattended agent incorrectly accepts unsupported claims.
• More detail, less success: fixed source order blocks following an unexpected disconfirming lead.

The bounded-context orchestration model provides a computational account only for closed-world workflows with explicit transition-relevant state and suitable barriers. Other environments need richer execution models; none of the conceptual dimensions above implies every workflow should use a deterministic scheduler.

Architectural diagnosis: first identify the failure mechanism—lack of applicability, wrong interpretation, missing method decision, failed activation, unavailable operation, context drift, weak competence, inadequate feedback, inappropriate human handoff, or poor warrant—then select a targeted intervention. Codification is one intervention in that space, not the destination of a universal pipeline. A method's supported domain and a system's actually completed task domain must be measured separately. Improving activation or tools may move the latter without modifying the former.

5. Literature, status of ingestion, and limits of transfer

'Available for ingestion' below means a publicly accessible primary text or full, usable scholarly/web source was found, not that a snapshot was downloaded, a license permits republishing, or the mandatory source-ingest workflow was run. Commonplace keeps reading snapshots local/ignored and tracks analyses separately; see source collection contract and the cp-skill-ingest workflow. Under copyright restrictions do not distribute primary texts through the tracked repository.

Source	What it can test	Existing ingest?	Source access checked 2026-10-31	Disposition
Wielinga, Akkermans & Schreiber (1998), competence theory	Method competence → conceptual refinement → operational choices; possible competence loss	Yes	Full author/institutional PDF surfaced	Reuse existing ingest; do not duplicate
Parasuraman, Sheridan & Wickens (2000), automation levels	Function allocation distinct from full-task automation and human performance	Yes	Full PDF accessible	Reuse existing ingest
Bainbridge (1983), Ironies of Automation	Human exception burden, automation failure and deskilling	Yes	Existing ingest has full user-supplied PDF capture; publisher paywall	Reuse existing ingest
Norman (1989), NASA-hosted original report	Automation feedback/exception boundary; delegated function versus full role	Yes, this run	Full 14-page ICS Report 8904 captured; scanned two-column layout, so extracted text is noisy	Ingested; the journal reprint is a different publication and was not captured
Suchman (1985), Plans and Situated Actions, PARC report ISL-6	Plan ≠ full determination of situated activity; plan-as-program versus plan-as-resource	Yes, 2026-11-02	The 1987 book's course URL returns 404 and its Wayback capture has no text layer. The 1985 thesis, the book's earlier version, is hosted on bitsavers as a 163-page scan with an OCR text layer	Ingested in full. Carries the plans-as-resources argument, the instruction-following mechanisms, the false alarm and garden path, and the asymmetry conclusion. Does not carry book-only formulations; those stay secondhand via the readings below
Dittrich (2023), Re-re-reading Suchman	Secondary orientation to Suchman's plans-versus-situated-action argument and the second-edition additions	Yes, this run	Public blog post, full HTML	Ingested as a secondary pointer. It reads the second edition, Human-Machine Reconfigurations, with the situated-action definition at p. 70; it is not the 1987 argument
Duguid (2012), On rereading. Suchman and Situated Action	Plans as interpreted resources versus executed programs; conformity pressure hiding plan gaps	Yes, this run	Journal PDF, 7 pages, full text	Ingested as a secondary reading by a member of Suchman's PARC circle; sympathetic, relays rather than quotes
Umeå HCI course (1997), summary of Plans and Situated Actions	Outline of the 1987 argument, the copier study and its three design problems	Yes, this run	Public HTML mirror, about two thousand words	Ingested as an uncredited student-style summary of the first edition; no page numbers, some loose attributions
Church–Turing thesis, SEP entry	Effective methods as the no-insight limiting case; level-relativity of "the method"	Yes, this run	Public full HTML article	Ingested; secondary scholarship with Copeland's interpretive position, not Turing's text
Operationalism, SEP entry	The discipline's own sense of operationalization and its known failure modes	Yes, this run	Public full HTML article	Ingested; supplies the three conditions in section 0 and the Margenau dilemma
Plotkin (2004), origins of SOS	Operational semantics is a rule-specified transition relation, distinct from execution by an implementation	Yes, this run	The CiteSeerX copy is no longer served; captured from the author's homepage	Ingested; contrast case that keeps "operational" from collapsing into "executed"
OMG, CMMN 1.1 specification	A deployed standard that keeps model execution, performer type, activation and discretionary planning as separate controls	Yes, this run	Normative 144-page PDF captured; figures and lifecycle diagrams lost in text conversion	Ingested; a design standard, not evidence that the design works
Haynes et al. (2009), surgical checklist	Human operationalization without task automation, with outcome data	Yes, this run	Publisher returns HTTP 403 to automated capture; captured from a user-supplied PDF of the full article	Ingested; a before-after bundle study, so no component is isolated as the cause

The sources' meanings do not transfer unchanged: operational semantics fixes rules in programming-language theory; operationalism addresses measurement and scientific concept meaning; operational method construction in knowledge engineering moves toward a task-specific executable control strategy; automation levels in human factors classify allocations and interaction. None licenses a universal equation 'operationalize = formalize = automate'.

Ingest status after the third revision: all seven candidates are ingested (Norman, both SEP entries, Plotkin, CMMN, Haynes, and Suchman's 1985 thesis in place of the 1987 book). The three secondary readings (Dittrich, Duguid, and a 1997 course summary) remain for book-only material and are marked as secondhand where used. Claims specific to the 1987 or 2007 editions still need those editions. The three earlier reports are reused. Public retrieval does not establish a copyright license for committing a full source; the snapshots stay ignored and checksummed.

6. Worked cases from the ingested sources

Each case below is read from one ingest. The ingests record their own limits; every transfer to LLM executors is by analogy unless the mechanism is shared.

6.1 The effective method: the limiting case where operationalization and automatability coincide

Copeland's four conditions define an effective method: finitely many exact instructions, a result in finitely many steps, performable by an unaided human with paper and pencil, and demanding no insight, intuition or ingenuity (Church–Turing ingest). The thesis and its easy converse say that a method operationalized to this level is exactly one a Turing machine can carry out. Human computers executing such methods were later replaced by machines doing the same work. That is function-level automation following operationalization with decision autonomy held at zero on both sides: neither executor decided anything.

Two consequences for the workshop:

• Operationalization entails automatability only for no-insight executors. Beyond condition 4 it does not. This is the baseline against which the LLM case differs, and it explains why the first draft's "neither sufficient nor necessary" claim in section 3 holds: the claim is about executors that are permitted insight.
• "The method" is level-relative. At the level of weights and inference code, an LLM run is mechanical in the technical sense. At the level of the retained task instructions, the same run supplies decisions no method settled. So any claim that K is operationalized for E must name which artifact counts as the method. Without that, "computationally closed but methodologically open" in the closure note looks like a contradiction with classical computability. It is not; the two readings name different artifacts.

The ingest warns against the equivalence fallacy: the thesis bounds what a human following an effective method can do, not what machines can generate. Do not argue from it to a ceiling on machine judgment, and do not read "mechanical" as "without judgment-like output".

6.2 Norman's handover: automating a function versus automating a role

Norman holds the captain's delegation fixed and swaps the delegate: the autopilot or the first officer (Norman ingest). Both "automate" control from the captain's view. Only the human delegate would say "I seem to be correcting this thing more and more." In two incidents the autopilot compensated silently for a growing fault, and the crew learned of it only when the compensator reached its limit and the least recovery time remained.

The mechanism Norman names is the one this workshop needs. The designer's task "is completed when the device functions as requested", and reporting is secondary because "the automation itself doesn't need it." Read in this workshop's terms: a task definition T written for executor E drops the functions E does not consume. Anomaly reporting served the surrounding crew, not the control loop, so it fell outside T. This is a mechanism for section 0's claim that T owns the application area and success criteria. It adds a requirement: T must name the functions the previous executor supplied to its surroundings, or operationalizing for the new executor silently removes them.

The case also separates two things the first draft ran together under "automation coverage":

• automating a delegated function: the autopilot holds heading and altitude;
• automating the full role of the previous executor: everything the first officer did in that seat, including status and anomaly talk.

Norman adds that specific monitors are easy to operationalize (any competent programmer could write one for yoke compensation) while the general case, the next slightly different anomaly, needs "a monitoring of its own monitoring" and a system model nobody knows how to build. That is the escalation boundary in section 3, item 5, again: escalation is warrantable within a defined anomaly class and unsolved beyond it.

Limits: three incident narratives and one informal simulator run. The "first officer would have said something" premise is untested, and Norman's own fuel-leak replication shows crews missing exactly that cue. The analogy to agents rests on compensation with a saturation limit, which an agent's hidden repairs may not share.

6.3 CMMN: four separate controls in a deployed standard

The OMG case-management standard models work that "cannot be orchestrated by a predefined sequence of Tasks" (CMMN ingest). It keeps four controls apart that the workshop's dimensions also keep apart:

CMMN control	What it decides	Workshop dimension
Engine executes the case model's state semantics (sentries, lifecycles)	Whether the model is executed at all	Execution of an operationalized arrangement
Task performer type: HumanTask, ProcessTask, DecisionTask	Who or what does each unit of work	Function-level automation
ManualActivationRule	Whether enabled work starts by itself or waits for a person	Unattended continuity
Discretionary items in PlanningTables, gated by Roles and ApplicabilityRules	Who may select and order work at run time, within a declared catalogue	Decision autonomy

The mapping gives a non-LLM instance of an operationalized, engine-executed case model with no function-level automation and no decision autonomy for the engine. Executable, automated and autonomous are three predicates here, and the standard sets each independently.

The same knowledge also appears in different forms for different consumers: engine-evaluated rules over the case file, planning tables and filters for the human planner, and tacit knowledge that stays with participants. That is executor-relative operationalization in the standard's own structure.

Where the mapping fails: the standard's executors are human case workers, and its discretion is a declared catalogue, not open judgment. It records no outcome data, so it shows that a two-phase discretion boundary was institutionalized, not that it works. The engine's "execution" is of a state model, not of the knowledge work; the work itself stays with the performers. Transfer to LLM executors holds only for the engine-enforced-state versus judgment split.

6.4 Three senses of "operational"

The ingests fix three senses that the KB now uses or touches:

1. Operationalism (Bridgman, then Feest and Chang): a concept's meaning given by operations that apply it; in its surviving form, a partial and provisional specification of indicators for a purpose (operationalism ingest).
2. Operational semantics (Plotkin): a rule-specified transition relation that gives a language its meaning. It is distinct from an implementation that executes it, and executable rules such as TYPOL's Prolog reading are a further step with their own efficiency problem (Plotkin ingest).
3. operationalized-from (ADR 054): a methodology-to-procedure lineage edge.

None of these is "executed" or "automated". Plotkin keeps specification and execution apart even when the rules run; the operationalism sense names indicators, not steps. The workshop's provisional sense, making K usable for T by E, is a fourth use, and the vocabulary collision ledger then carried an "operational" row naming all four senses and their writing rules. Two questions this section raised were settled on 2026-10-31 outside the workshop. At that point, the codification definition distinguished its criterion from Plotkin's sense and operationalism, and conjectured that a formal semantics existed for the artifact's language, located by the clerk test and corroborated by many consumers held to one reference. Five surfaces were aligned to that criterion. ADR 124 supersedes that formalizability criterion: representational form now owns membership through path-relative localization and a governing semantic reference; codification names the move by rewriting or adoption. One question stays open: the constraining definition counts operational definitions as constraining without qualification, while the operationalism source holds that they are partial and cannot show their own validity. That belongs to a separate consistency pass.

6.5 Haynes: operationalization without function automation, with outcome data

The WHO Safe Surgery Saves Lives program turned guideline knowledge into a 19-item checklist confirmed aloud at three fixed junctures (Haynes ingest). Eight hospitals translated it and "adjusted [it] to fit into the flow of care". Three sites moved antibiotic administration into the operating room to make one item performable. No function was automated. Every decision stayed with the surgical team.

Three readings for the workshop:

• Operationalization acted on the setting, not only on the method. Fitting the checklist to each site changed available operations and the activation point as well as the text. That is the task-, executor- and setting-relative relation of section 0, in a case with no computation at all.
• An operationalized procedure did not settle execution. Adherence to all six measured safety steps rose from 34.2% to 56.7% of patients. Omissions stayed frequent. Operationalization, actual execution and outcome quality came apart in the measurements, which is the three-proposition split at the end of section 3.
• Peer-performed confirmation is a designed feedback function. The checklist assigns spoken confirmation to roles so the team knows whether steps were done. That is a human-side answer to the missing cross-operator feedback in Norman's case, section 6.2.

Limits: a before-after bundle study with no concurrent controls. Briefings, debriefings, systems changes and observation co-varied with the checklist, so the study identifies the program-level association and no component. Transfer to LLM executors is analogy; social accountability and observation effects have no established LLM counterpart.

The same artifact, a different executor. In 2009 no computational executor could run the checklist, so "operationalized, not automated" was the only state available. An LLM agent can now administer it: prompt each item at its juncture, take the confirmations, record omissions. Nothing in the artifact changed. Three things follow for the workshop. Automatability is a property of the artifact and executor pair, which is the executor-relativity of section 0 observed on one artifact across time. What moves to computation is the reader's function, not the surgical role, so the task boundary still decides what "fully automated" would mean, as in section 6.2. And whether the outcome gain survives the transfer is an open empirical question, since the study attributed it to the bundle and the oral pause among humans may be part of what worked. A method operationalized for human executors in natural language is therefore a candidate for LLM execution without rewriting; what remains human is set by the task's functions and the executor's operations, not by the form of the artifact.

6.6 Suchman: a plan is a resource for an executor that interprets, and a program only by substitution

The primary text is now ingested: Suchman's 1985 PARC thesis ISL-6 (Suchman 1985), the earlier version of the 1987 book. Page numbers below are the report's printed pages. The three secondary readings (Dittrich, Duguid, Umeå 1997) stay in use only for what the 1985 text does not contain; each such use is marked. The 1987 book and the 2007 second edition remain uningested, so formulations specific to them (the "plans are resources for situated action, but do not in any strong sense determine its course" sentence, the second edition's p. 70 definition, the "discursive tools" phrase) are still secondhand.

The target position, in Suchman's own citation. Her quarrel is with the identification of a plan with a program. She quotes Miller, Galanter and Pribram: "A Plan is, for an organism, essentially the same as a program for a computer", and glosses the move as making the plan "substitutable for the action, insofar as the action is viewed as derivative from the plan" (p. 27). The cognitive-science remedy for a vague plan is to render it "more 'precise' and axiomatic" (p. 123). Duguid's line between a device executing a plan and a human using one as a resource is therefore her own distinction, stated at the source as plan-as-program versus plan-as-resource.

Her alternative. Plans "are not faulted versions of scientific models of action, but rather are resources for people's practical deliberations about action", projective before the fact and retrospective after it (p. 35). Vagueness "is not a fault but, to the contrary, is ideally suited to the fact that the detail of intent and action must be contingent on the circumstantial and interactional particulars of actual situations" (p. 123). The specification problems of cognitive science "have less to do with action, than with the project of substituting definite procedures for vague plans, and representations of the situation of action, for action's actual circumstances" (p. 33). The thesis's own evidence for all this is one qualitative case, a plan-recognizing copier help system with first-time users; the ingest's limitations section records that the in-principle claims are argued, not tested.

The test this sets for the workshop, now on primary ground. Operationalizing K for an executor that can interpret produces a resource. Turning it into a program is the substitution Suchman names, a separate step with its own conditions, and section 6.1's effective method is the limiting case where the substitution is complete because the executor is forbidden to interpret. LLM executors interpret natural-language plans in context, so they fall on the resource side while remaining computational. Suchman's text does not say which of her conclusions survive for such executors; the ingest marks that transfer as analogy.

Mechanisms the primary text supplies. Two of them replace leads that section 6.6 previously took from the secondary readers, and one is new:

• Detail substitutes for a missing feedback channel. Suchman relays Burke's assembly-task study: non-interactive instruction tends to "overelaborate" descriptions "in an apparent attempt to anticipate possible troubles, and to compensate for the lack of opportunities for their in situ clarification", whereas face-to-face instructors "initially provide minimal descriptions, and then monitor the apprentice's actions for evidence of the description's adequacy or inadequacy" (p. 69). This gives Duguid's instruction-regress anecdote a mechanism: added specification is what an author does when the executor cannot ask. It is the "more detail, less success" counterexample of section 4 with its cause named, and it predicts that an executor with a clarification channel needs less fixed detail than one without.
• Authoritative instructions deflect fault to the execution and filter the record. Via Amerine and Bilmes, Suchman holds that instructions "filter out of the retrospective account of the action, or treat as 'noise,' everything that was actually done that the instructions fail to mention", and that "as long as instructions are viewed as authoritative, the preference in remedying a faulted outcome is to account for the failure in outcome without discrediting the instruction" (p. 67). This is the mechanism behind the conformity-pressure lead that reached the workshop thirdhand through Orr via Duguid: a retained method that counts as authoritative suppresses both the record of what the executor did beyond it and the attribution of failure to it. The claim now has a primary statement at the mechanism level, with Suchman's source for it an unpublished 1979 manuscript and a third-grade science class; Orr's technicians remain the uningested field case.
• Constraining is the design's substitute for situational access. The copier "relies upon a partial enforcement of the order of user actions within the procedural sequence" to "compensate for the machine's limited access to the user's actions" (p. 71). The designer's "real project" is "to engineer alternatives to interaction's situated properties", chiefly by substituting "a description of the situation of action, for access to the actual situation" (p. 124). Read for the workshop: when an executor cannot see the situation, the author constrains the admissible action sequence so that observed effects imply conditions. That is the constraining operation with its motive stated, and it suggests which executors need it: those whose access to the task situation is a description rather than evidence they can gather.

Two breakdowns the copier could not detect, now from the source (section 7.5, p. 114): the false alarm, where "a misconception on the user's part produces evidence of an error in her actions where none exists", and the garden path, where the misconception "produces an error in her action, the presence of which is masked" because the faulted action satisfies the design under another interpretation. "In both cases, the user's trouble is unavailable to the system." LLM executors repair both, often silently; the garden path is the structure of silent disambiguation.

Still secondhand. The Umeå summary's three design problems (extend the machine's access, make its limits clear, compensate for what it lacks) are not in the 1985 text; the compensation clause is (p. 71), the list is not. Duguid's Orr case and his Moore's-Law remark about principled objections appearing practical are his, not Suchman's, and keep the status the previous revision gave them.

The Haynes case in section 6.5 is the counterweight: a rigid, read-aloud procedure improved outcomes. Suchman's own text admits the contrast without resolving it: her Gladwin epigraph has the European navigator, once the plan is made, performing "almost mechanically the steps dictated by his training and by his initial planning synthesis" (p. 21). When a plan is good enough to execute without interpretation is exactly the question condition 2 in section 0 leaves open.

6.7 What the cases say about the executor's range of operations

Condition 2 in section 0 asks for a typed range of operations between open judgment and codified steps. The cases bracket it:

• The effective method sits at one end: operations are rule applications with no insight.
• CMMN's engine sits near it: evaluating sentries and rules over a case file.
• CMMN's human planner, Norman's first officer and Haynes's surgical teams sit at the other end: selecting work from a catalogue, noticing trends and reporting them, and skipping steps.
• The LLM executor in the second example table of section 0 sits between: it follows a retained method where one exists and supplies decisions where it does not.

No test here types that middle range. Doing so is the next concrete step for the definition, and it is what the candidate experiment in section 7 would have to log per decision.

7. Architectural predictions and proposed discriminating experiments

P1 — task-relative operationalization does not entail generalization. With T and its application area fixed, giving E better activation, source access and state can improve successful execution without altering K's domain of applicability. Separately test extending K or redefining the task as T' while preserving E/S. Better T performance is not by itself evidence that K works on T'.

P2 — method detail can help or harm. In tasks with late-arriving information, a step-fixed script may do worse than purpose- and bound-guided execution using the same evidence and executor, especially if the pre-fixed path excludes discovery. Compare outcomes and actual evidence encountered, not prompt length alone.

P3 — methodological incompleteness can coexist with complete computational execution. An LLM may provide unarticulated method decisions and complete a full bounded task unattended. Log which decisions came from retained method, which from model judgment, and which from symbolic tools; judge quality independently. The test must not quietly exclude human recovery, authorization or approval that was required for completion.

P4 — automation and decision autonomy diverge. Replace a human operator with a fixed code path to increase task automation while leaving choice latitude unchanged, and separately delegate method selection to an LLM without automating physical implementation. A metric claiming both interventions are the same progress is defective.

P5 — autonomy and warrant diverge. Removing an approval gate can raise computational closure but leave discrimination worse; improving an independent oracle can expand the domain of warranted unattended execution. Measure false acceptances and missed exceptions as well as throughput.

Candidate Commonplace experiment: define T explicitly, including the application area, acceptance criteria and authority boundaries; select one existing research method and keep the model pinned. Run (a) bare task, (b) relevant methodology cue, (c) cue plus the same method with improved access/state/recovery, and (d) the same support with stronger step constraints. In a separate generalization experiment, propose T' with a wider application area and independently check whether K still applies. A second contrast transfers one approval or method-choice function from human to LLM while holding T and evaluation fixed. Log source activation, intervention responsibility, revision fidelity, final correctness, fallback cases, cost and horizon. None of these comparisons has been run here.

Withdrawn test, 2026-10-31. A bounded three-arm design for P2 and the Suchman question was written and withdrawn the same day. It would have tested how one class of executor responds to the form in which a method is supplied, which is an empirical claim about LLM executors that the determinability note already carries as working theory. It would not have tested this workshop's claims, which are distinctions, and a distinction is refuted by a case it misclassifies, not by a run. P2 through P5 remain stated as the empirical consequences a future workshop on instruction form could test. One further design was considered and set aside as too complicated to run well: give two executors the two rival definitions of operationalization, the scalar and the task-relative one, as working guidance on the same tasks, and compare what each does with them. It would test the definitions' usefulness to an executor, not their truth, and separating that from the executors' other differences would need more cases and controls than the question is worth now.

8. Extraction candidates

What the exploration holds that the library does not, with the obstacle to each. The last two rows were extracted on 2026-10-31 and are listed in the disposition; the escalated-cases row was checked on 2026-11-01 and found covered; the closure-artifact and Haynes-transfer rows were desk-checked on 2026-11-02, the first amended into the closure note and the second found covered. The section 4 table was checked the same day against the library and adds a routing index, not a mechanism; the README records the placement of each mechanism.

Candidate claim	Where it sits here	Obstacle
A plan is a resource for an executor that interprets and a program for one that cannot; removing the interpreter is a separate step	6.6	Primary since 2026-11-02: Suchman 1985 pp. 27, 33, 35, 123. The thesis argues the distinction and shows one system class failing; it does not test it. Still needs a Commonplace case for the LLM-executor transfer
Conformity pressure hides fallback and its lessons: an executor held to apparent compliance suppresses the signals that method promotion needs	6.6, Amerine and Bilmes via Suchman 1985 p. 67; Orr via Duguid	Mechanism now stated secondhand at the source (authoritative instructions filter the record and deflect fault to execution). Orr's field case stays thirdhand and unpurchased; an agent-runtime instance would still be the better evidence. Would qualify the two-layer execution note
A closure claim must name which artifact counts as the method, since the same run is mechanical at one level and judgment-laden at another	6.1	Checked 2026-11-02: the closure note's scope section was relative to pathway and horizon only, and spoke of "the retained methodology being assessed" without saying the claim must name it. Done: two sentences added to that section, with the four-combinations table's third row as the worked instance
Operationalizing K for a task yields a partial indicator hypothesis, checkable only against the part of K it leaves out	0, conditions 1 and 3	Transfer by analogy from operationalism; no Commonplace case where the residue was used to catch a wrong operationalization
A full-automation claim must exclude escalated cases in advance or report coverage as partial	3, item 5	Checked 2026-11-01: the closure note's declaration section already requires the horizon and the treatment of failures and names ending observation before the next human intervention as the masking move; covered, no amendment
Discretion as a declared, versioned catalogue rather than an absence of specification	6.3, CMMN	A design standard without outcome data; needs a Commonplace case
A method operationalized for human executors in natural language becomes a candidate for LLM execution without rewriting; what stays human is set by the task boundary and the executor's operations, not by the artifact's form	6.5	Checked 2026-11-02: covered jointly. The representational-form definition says natural-language content gets its consequences from interpretation by a model or a human and that form is not consumption path, which is the no-rewrite half; the actionable-methodology definition's task element says a task written for one operator must be restated for another, which is the what-stays-human half; the closure note's per-function reporting is the allocation. The skills-derive note answers a different question, how skill content relates to methodology content, and does not conflict. No amendment; the Haynes transfer stays a possibility, not a case
Silent compensation with a limit turns drift into a late, compressed failure	Norman ingest	Needs an agent-runtime instance before it earns a note
Which sense of "operational" each KB use carries	6.4	Done: ledger row and definition scoping
Task definition owns the application area; operationalization is relative to task, executor and setting	0, 6.2	Done: actionable-methodology amendment

9. Disposition

1. Define the application area in task T, not inside operationalization. Operationalization is the task- and executor-relative transformation that makes K usable for T by E in setting S. Theory → methodology and methodology → skill are possible realizations of this same task-relative operation, not two mandatory meanings. Generalizing K or extending T is separate, and any newly discovered T' needs a separately warranted scope claim.
2. Preserve current Commonplace definitions of actionable methodology, constraining, codification, and methodological/computational closure; do not create competing 'executability' or 'operationalization' definitions on purely conceptual grounds. Of the five coordinates in the central result, only generality and operational integration name something the existing definitions do not. Situated executability is the actionable relation, now that the definition carries the task; methodological coverage is closure without the settling condition; constraining is already defined.
3. Treat automation and autonomy separately in future comparisons: allocate actual task functions to human/computation; separately record discretionary and authorization boundaries, plus which human interventions remain required over the declared horizon. Computational closure is useful for absence of required human decisions, but not a complete proxy for discretionary authority.
4. Retain the narrower lineage meaning of 'operationalized-from' as the methodology-to-procedure artifact relation. It is compatible with, but not equivalent to, the proposed task-relative sense. When provenance matters specify the source artifact and kind of transformation; when efficacy matters specify T, E and setting. No ADR change without separate evidence.
5. Do not infer fully automated LLM work from operationalization alone. Demonstrate executor capability and function closure under explicit constraints, then separately demonstrate warrant and adequate outcome quality. Lack of a deterministic procedure is not by itself a blocker.
6. No new machinery or new vocabulary. Two existing definitions were amended (items 7 and 9); no term was added. The workshop's remaining distinctions are useful for architectural decisions, but causal superiority and the need for further vocabulary await the scoped tests above.
7. One extraction is ready without a test. The claim that a task definition fixes the application area and success criterion, and that operationalization is relative to task, executor and setting, is conceptual and now has a mechanism from Norman (a task written for one executor drops the functions that executor does not consume) and a limiting case from the Church–Turing material. Extracted on 2026-10-31 as an amendment to the actionable-methodology definition: the task is the relation's fifth element, with the dropped-functions mechanism and three misuse cases. The rest of this workshop stays here until a test discriminates.
8. Source status. All seven candidates are ingested. Suchman's 1985 thesis stands in for the 1987 book; the CMMN precedent shows a 163-page report is within what the collection ingests. Three secondary readings remain for book-only material. Orr's Talking About Machines is the one primary text still missing, and it is available only as a licensed ebook; it is not bought, because its candidate accepts an agent-runtime instance instead. Nothing in items 1 to 7 depends on either.
9. Codification's criterion was sharpened from this workshop's sources. The Church–Turing clerk test, the Plotkin and operationalism contrasts, and the question whether notation or consumer decides codification led to the definition stating its criterion as a tested conjecture (section 6.4). That work was done directly in the definition and is not workshop content; the Church–Turing ingest's open tension on notation versus consumer is answered there.