Script¶
Core Idea¶
A script is a stored representation of a familiar situation as an ordered sequence of events, including the roles that typically fill each step, the props or resources involved, the typical preconditions and termination conditions, and the standard variations. Where a schema is a generic structured knowledge representation — a slot-and-filler bundle that may or may not be temporally ordered — a script is specifically the temporally and causally ordered schema: this happens, then this, then this, with each step setting up the preconditions for the next, and with each role available to be filled by different actors on different occasions. The structural commitment is that some recurring situations are stored not as facts about the world but as procedures with slots, and that future encounters with a matching situation are interpreted by binding the current particulars to the script's roles and predicting the next step from the script's sequence.
Once a script is active, it does powerful inferential work. It lets the agent skip unmentioned-but-expected steps without surprise, fill in missing detail by default, predict what is about to happen, and detect deviations as anomalies that need explanation. The same mechanism that makes routine situations effortless also makes deviations conspicuous: script breach — the predictive failure when observation does not match the script's expected next step — is the diagnostic signature of the pattern, and it is what distinguishes script-based interpretation from mere recall. The structural skeleton has a recurring set of parts: a triggering situation that activates a stored script; an ordered sequence of steps the script predicts; roles, the slots filled by particular actors on each performance; props, the resources the script presupposes; preconditions and termination conditions that bracket the script's applicability; default fillers that supply expected values for unstated particulars; the breach that fires when observation deviates from prediction; and composition, by which larger procedures are built from nested and sequenced scripts. The four commitments that mark the type — temporal ordering, role-binding, slot-filling with defaults, and breach-diagnosis — travel together, and it is their conjunction that distinguishes a script from its near-neighbors, none of which carries all four.
How would you explain it like I'm…
Restaurant Story
Know-What's-Next Story
Ordered Situation Recipe
Structural Signature¶
a triggering situation that activates a stored representation — a temporally and causally ordered sequence of steps — role-slots filled by particular actors on each performance — props and preconditions/termination conditions bracketing applicability — default fillers supplying unstated particulars — a breach that fires when observation deviates from the predicted next step — composition by nesting and sequencing of sub-scripts
The pattern is present when each of the following holds:
- A triggering situation. A recurring situation whose recognition activates a stored procedural representation rather than a bare fact.
- An ordered sequence. Steps in temporal and causal order, each setting up the preconditions of the next — the commitment that distinguishes a script from an unordered schema.
- Role-slots. Generic slots in each step, bound to particular actors on each performance, so the same script runs with different fillers.
- Props and bracketing conditions. Presupposed resources, plus preconditions and termination conditions that bound where the script applies.
- Default fillers. Expected values for unstated particulars, letting the agent skip unmentioned-but-expected steps and fill in missing detail without surprise.
- A breach operation. A continuously-running comparison of observation against the predicted next step; a mismatch fires as an anomaly needing explanation. This breach is the diagnostic payload that distinguishes script-interpretation from mere recall.
- A composition invariant. Larger procedures are built by nesting and sequencing smaller scripts, covering a vast situation space with a modest composable library.
These four commitments — temporal ordering, role-binding, slot-filling with defaults, and breach-diagnosis — travel together; their conjunction is what marks the type apart from its near-neighbors.
What It Is Not¶
- Not a schema. See
schema. A schema is the generic structured-knowledge bundle — slots and fillers — that may or may not be temporally ordered. A script is the specifically temporally-and-causally ordered schema. The added commitments (sequence, breach-on-next-step) are what make a script more than a schema. - Not sequencing. See
sequencing. Sequencing is the bare ordering of items. A script adds role-slots, default fillers, bracketing conditions, and breach-diagnosis on top of order; an ordered list with no slots to bind and no prediction to violate is sequencing, not a script. - Not an algorithm. See
algorithm. An algorithm is a precise, deterministic procedure guaranteeing a result. A script is a defeasible expectation about how a familiar situation typically unfolds, tolerant of variation and informative precisely through its breaches; it predicts rather than computes. - Not a ritual. See
ritual. A ritual is a socially-prescribed, often symbolically-charged performance whose correctness is normative. A script is a descriptive cognitive representation used to interpret and predict; a ritual may be one kind of situation a script represents, but the script is the interpretive structure, not the prescription. - Not a mental model. See
mental_model. A mental model represents how a system works (causal structure). A script represents what happens next in a situation (temporal procedure). One supports counterfactual reasoning about mechanism; the other supports prediction of the next step. - Common misclassification. Calling any stored knowledge of a routine a "script." The catch: check for all four commitments — temporal ordering, role-binding, defaults, and breach-diagnosis. Knowledge that is unordered (schema), has no slots (sequencing), is deterministic (algorithm), or is prescriptive (ritual) is missing one of the conjuncts that define the type.
Broad Use¶
- Cognitive science. The canonical restaurant script — enter, be seated, read the menu, order, eat, pay, leave — and the broader claim that much of everyday cognition is script-driven rather than reasoned; story comprehension and default inference in language understanding run on script-like representations.
- Service design and UX. Customer journey maps are scripts: step-ordered sequences with role-slots (customer, agent, system), preconditions (account state, prior step completion), and variations (express versus full path, error branches).
- Software and automation. Scripts in the literal sense — shell scripts, test scripts, CI/CD pipelines, playbooks — are ordered sequences of operations on parameterized objects; behavior trees in robotics and game AI are the same structure with branching.
- Law and procedure. Legal proceedings, voting procedures, parliamentary rules, surgical protocols, and aviation checklists are scripts with required ordering, role-slots, and termination conditions — the script form is what makes "due process" meaningful.
- Social interaction and ritual. Greeting routines, dinner-party scripts, weddings, and funerals; cultural fluency is partly script fluency — knowing what comes next in the situations one is in.
- Robotics and embodied AI. Action sequences, manipulation scripts, and task-and-motion plans — ordered procedures with parameter slots and precondition checks.
- Pedagogy. Lesson plans, lab protocols, and training curricula are scripts with role-slots, ordered steps, and termination conditions.
Clarity¶
Naming the script representation separates three things that talk of routine behavior routinely conflates: knowledge of what is true (a schema or fact), knowledge of what to do (a procedure or script), and knowledge of how to do it (a skill or embodied competence). A waiter has all three about restaurant service, and failing to distinguish them is much of what makes "tacit knowledge" seem mysterious — the procedural layer, the script, gets folded into either the factual layer or the skill layer and thereby disappears as an object of analysis. Pulling the script out as its own representational type makes the procedural knowledge inspectable: one can ask what the steps are, what fills each role, what the preconditions are, independently of the facts the agent knows and the motor skills they have. The frame also corrects a common error: treating deviation from script as a flaw, when it is frequently the most informative thing in the situation. Because the script generates a prediction at each step, a mismatch between prediction and observation is a signal, not noise — anomaly detection in long-running systems often reduces precisely to script-breach detection. The clarifying move is to recognize the breach as the script's payload rather than as a failure of the script: the value of having a script is not only that it makes the routine effortless but that it makes the non-routine conspicuous, and naming the breach as the diagnostic signature makes that value explicit and usable.
Manages Complexity¶
A script compresses a recurring situation's interpretive demands to a few diagnostic operations: identify the script the situation triggers, bind the current particulars to the script's roles, locate the current step in the sequence, predict the next step, and compare the actual to the predicted. Most situations the agent encounters require only the first four operations — recognition, binding, location, prediction — and generate no anomaly, so they are handled with almost no deliberative effort. Only the few situations that produce a mismatch at the fifth operation demand attention. This is a radical reduction in cognitive load for routine encounters, because the overwhelming majority of moments in a familiar situation are disposed of by the script without any reasoning at all, and the agent's scarce attention is spent only where the script's prediction fails. The compression is what makes fluent functioning in a complex social and physical world possible: an agent who had to reason explicitly about every step of every familiar situation would be paralyzed, whereas an agent equipped with scripts treats the routine as effectively free and reserves deliberation for the genuinely novel. The same structure also manages complexity through composition. Larger procedures need not be represented as monolithic sequences; they are built by nesting and sequencing smaller scripts — the restaurant script nested inside a date-night script nested inside a meeting-the-parents script — so that a vast space of complex situations is covered by a modest library of composable scripts rather than an unmanageable enumeration of whole scenarios.
Abstract Reasoning¶
Script-based reasoning supports inference about what was not explicitly mentioned in a story or report: the reader fills in the unstated steps from the script, so that a narrative naming only a few events is understood as the whole sequence. It supports prediction of the next likely event given a recognized situation, which is the basis of the fluency with which agents anticipate what is about to happen in familiar settings. It supports anomaly detection via script-breach, turning the script's prediction into a continuously running check against observation. It supports role-based substitution: the same script run with different actors yields predictable variations, so that knowing the script lets an agent reason about how the situation will differ when the roles are filled differently. And it supports script composition, the inference that a large unfamiliar procedure can often be decomposed into nested and sequenced scripts the agent already has, so that novel situations are made tractable by recognizing their familiar sub-scripts. Each of these inferences is stated in terms of the script's ordered-steps-with-role-slots structure rather than in terms of any particular content, which is why they hold across substrates: the inference that unstated steps can be filled in from the script applies identically to a story about a restaurant, a customer-support transcript missing intermediate steps, and a partially-logged software pipeline, because in each case a recognized script supplies the defaults the record omits.
Knowledge Transfer¶
The script formalism transfers across substrates because its four commitments — temporal ordering, role-binding, slot-filling with defaults, and breach-diagnosis — are stated in structural terms that carry from cognition into software, services, law, and robotics with little translation. The cognitive-science formalism ports into service design as customer-journey-mapping: the role-slots and precondition-postcondition machinery of the original restaurant-style scripts directly populate service-blueprint methodology, so that a service is designed by authoring and instrumenting a script. Cognitive scripts port into automation, where literal software scripts and behavior trees inherit the slot-binding and sequencing logic, and test scripts borrow the precondition/action/postcondition structure wholesale. The legally-rigorous ordering-with-role-slots pattern ports from procedural law into medicine, where surgical timeouts and procedural protocols adopt it — the same script discipline that makes a contract enforceable makes a checklist effective, because both depend on the right steps occurring in the right order with the right roles filled. And the pattern ports from robotics into embodied AI, where hierarchical task networks and behavior trees carry the script structure to autonomous agents, with precondition-checking and recovery-on-failure inheriting the script's anomaly-handling directly.
The role mappings that make these transfers reliable are direct. The triggering situation maps to the recognized restaurant, the start of a support interaction, the filing of a case, the initiation of a pipeline, the beginning of a surgical procedure. The ordered steps map to the seating-ordering-eating-paying sequence, the journey-map stages, the arraignment steps, the build-test-deploy stages, the pre-op checklist items. The roles map to diner and server, customer and agent and system, judge and counsel, the parameterized objects a pipeline operates on, surgeon and circulating nurse. The breach maps to the menu handed at the door rather than the table, the support flow that skips a required verification, the procedure that omits a step, the pipeline stage that fails its postcondition. Because the structure and its breach-diagnostic are shared, a practitioner who has internalized scripts in one substrate recognizes them in another: a surgeon running a pre-op checklist, a pilot running pre-flight, a court running an arraignment, and a CI pipeline running build-test-deploy all instantiate the same structural pattern of ordered steps, role-slots, anomaly detection, and recovery branches. What transfers is the recognition that a recurring situation can be represented as a temporally ordered, role-bound, default-filling procedure whose predictive breaches are its most informative output — and the design discipline that follows, of authoring the steps, naming the roles, specifying the preconditions and termination conditions, and instrumenting the breach so that deviation becomes a detectable signal rather than a silent failure.
Examples¶
Formal/abstract¶
Schank and Abelson's restaurant script is the canonical worked instance, and it exhibits all four commitments that mark the type. The triggering situation is recognizing "I am at a restaurant," which activates a stored procedure rather than a bare fact. The ordered sequence is the causally chained steps — enter, be seated, read the menu, order, eat, pay, leave — where each sets up the next: ordering presupposes having read the menu, paying presupposes having eaten. The role-slots are generic positions bound to particulars on each performance: the customer slot is filled by me tonight and by you tomorrow, the server, cook, and cashier slots by whoever is working. The props and bracketing conditions are the presupposed resources (tables, menus, food, money) plus preconditions (the restaurant is open) and termination (the bill is settled and you exit). The default fillers do the inferential heavy lifting: told only "Mary went to a restaurant and later complained the steak was tough," a comprehender infers — without being told — that Mary was seated, ordered, and was served, because the script supplies those steps by default. This is exactly the abstract-reasoning payload: the script lets a narrative naming a few events be understood as the whole sequence. The breach operation is the diagnostic signature: if the script predicts "server brings food" but the story says the server brought a bill before any food arrived, the comprehender registers an anomaly demanding explanation — and that breach, not the smooth recall, is the script's most informative output. The composition invariant shows in nesting: the restaurant script slots inside a larger date-night script, so a vast situation space is covered by a small composable library.
Mapped back: Recognizing the restaurant is the trigger, enter-order-eat-pay is the ordered sequence, customer and server are role-slots, the inferred-but-unstated "she ordered" is a default filler, and the bill-before-food anomaly is the breach — the four commitments traveling together in one schema.
Applied/industry¶
A CI/CD pipeline is a script in the literal software sense, and instrumenting it through the frame turns silent failures into detectable breaches. The triggering situation is a code push or merge, which activates the stored pipeline definition. The ordered sequence is the causally chained stages — checkout, build, unit-test, integration-test, deploy-to-staging, deploy-to-production — each whose postcondition is the next stage's precondition: you cannot deploy an artifact that did not build, cannot run integration tests against a staging environment that was never provisioned. The role-slots are the parameterized objects the pipeline operates on: the commit slot bound to this particular SHA, the environment slot to staging or production, the artifact slot to the built image. The props and bracketing conditions are the presupposed resources (build agents, credentials, a container registry) plus preconditions (the branch is mergeable) and termination (a green deploy or an aborted run). The default fillers are the pipeline's defaults — the standard build flags, the default environment — supplied for unstated particulars. The breach operation is precisely where the engineering value lives: each stage's postcondition is a continuously-checked prediction, and a stage that fails its postcondition (tests red, deploy health-check failing) fires as an anomaly that halts the run and triggers a recovery branch (rollback, alert). The frame's design discipline maps directly onto good pipeline practice — author the stages, name the parameterized roles, specify each stage's pre- and postconditions, and instrument the breach so a deviation surfaces as a failed check rather than a silently-shipped bug. The identical structure governs a surgical pre-op checklist (ordered steps, surgeon and circulating-nurse roles, the breach firing when a step is skipped) and an aviation pre-flight, where the script discipline is what makes the omission of a step a detectable signal.
Mapped back: The code push is the trigger, build-test-deploy is the ordered sequence, the commit SHA and target environment are role-slots, the standard build flags are default fillers, and a stage failing its postcondition is the breach that the pipeline is instrumented to catch — the cognitive script formalism realized as automation.
Structural Tensions¶
T1 — Fluency versus Rigidity (the Cost of Defaults). Defaults make the routine effortless by filling unstated steps without surprise, but the same defaults blind the agent to cases where the unstated step actually differs. The script's economy is bought by not examining what it assumes. The failure mode is running a script whose defaults no longer match reality and never noticing, because the whole point of a default is that it is not checked — confabulating the expected step in place of the observed one. The diagnostic is to ask which steps the agent is filling from the script rather than from observation: where a default is load-bearing and the situation has drifted, the script will smoothly report what it expected instead of what happened, and only deliberately re-observing the defaulted step exposes the gap.
T2 — Breach-as-Noise versus Breach-as-Signal (Interpreting Deviation). A script breach can mean the world is anomalous or that the script is wrong, and these demand opposite responses. Treat every breach as noise and a stale script silently misinterprets each encounter; treat every breach as signal and the agent chases genuine routine variation as if it were a crisis. The failure mode is a fixed policy toward breaches rather than a judgment per breach. The diagnostic is to ask whether the deviation recurs: an isolated breach against a well-validated script is probably a real anomaly worth explaining, while a breach that fires on every recent performance is evidence the script itself has gone stale and needs revision, not that the world keeps misbehaving.
T3 — Ordered Steps versus Acceptable Variation (Rigidity of Sequence). Scripts commit to temporal and causal ordering, but real performances tolerate reordering and optional steps that the rigid sequence flags as breaches. The script cannot, on its own, distinguish a meaningful violation from a benign permutation. The failure mode is over-flagging — treating every departure from the canonical order as an anomaly, drowning real breaches in false ones — or under-specifying, leaving the script so loose it predicts nothing. The diagnostic is to ask which orderings are causally required versus merely customary: steps whose preconditions genuinely depend on prior steps are load-bearing sequence, while conventionally-ordered but causally-independent steps should be marked as permutable, so the breach fires only on violations that matter.
T4 — Recognition Speed versus Misclassification (Triggering the Wrong Script). The script's power begins with fast recognition of which script the situation triggers, but fast recognition is exactly what mis-triggers — a situation superficially like a restaurant activates the restaurant script and binds particulars to the wrong roles. Every subsequent prediction then inherits the misclassification. The failure mode is confident interpretation under the wrong script, where breaches are read as anomalies in the world rather than as evidence the wrong script is loaded. The diagnostic is to ask, when breaches accumulate early, whether the triggering itself was wrong: a cluster of mismatches right after activation more often means the wrong script was selected than that the right script met a strange world, and the repair is re-recognition, not step-by-step patching.
T5 — Composability versus Interface Mismatch (Nesting Seams). Large procedures are built by nesting and sequencing sub-scripts, covering vast situation space with a small library — but the sub-scripts must agree at their seams, where one's termination condition becomes the next's precondition. Composition presumes a fit that is not guaranteed. The failure mode is a seam mismatch: a sub-script terminates in a state the next sub-script's preconditions do not accept, and the breach fires at the boundary, hard to localize because each sub-script is internally correct. The diagnostic is to check the interface between nested scripts, not their interiors: when a composed procedure breaches at a transition, the fault is usually the handoff contract — one script's exit state versus the next's entry requirement — not either script's own steps.
T6 — Script versus Skill versus Fact (Which Knowledge Layer). A script is procedural knowledge — what to do, in order — distinct from factual knowledge (what is true) and embodied skill (how to execute). Conflating the layers is much of what makes expertise seem mysterious. The failure mode is misattributing a failure: drilling the script when the gap is actually skill (the steps are known but cannot be executed fluently), or teaching facts when the gap is a missing procedure. The diagnostic is to ask whether the agent knows the steps, knows the facts, and can execute — three separable questions: a learner who can recite the script but fumbles its execution has a skill deficit, not a script deficit, and authoring more procedure will not close a gap that lives in the embodied layer.
Structural–Framed Character¶
Script sits just on the structural side of the middle of the structural–framed spectrum — a mixed-structural prime with a 0.4 aggregate. Its core is a bare relational object: a temporally and causally ordered sequence of event-slots with roles, props, preconditions, default fillers, and a breach that fires when observation departs from the predicted next step. That four-part conjunction (temporal ordering, role-binding, slot-filling with defaults, breach-diagnosis) is a structural skeleton, but the prime carries a residue of its cognitive-science home and clusters in agentic substrates, which keeps it from reading as cleanly structural as percolation.
One diagnostic is fully clean: evaluative_weight is 0, since a script is neither good nor bad — a breach is a predictive mismatch to be explained, not a fault to be judged. The other four sit at the partial 0.5 mark, and each does so for a substrate-faithful reason. Human_practice_bound is 0.5 because, while many canonical scripts are human routines (the restaurant script, rituals, service flows), the same structure runs in non-human agentic substrates — a CI pipeline's ordered build steps, a robot's task sequence with precondition checks, a software script proper — so the pattern is agentic-substrate-bound rather than strictly human-bound. Vocab_travels is 0.5 because the cog-sci lexicon (script, role-slot, default filler, breach) carries to software and robotics fairly directly, with only light translation. Institutional_origin is 0.5 because the prime was formalized in cognitive science and knowledge representation, a soft disciplinary origin rather than a hard institutional one. Import_vs_recognize is 0.5 because invoking the prime half-imports the role-slot-and-breach interpretive frame and half-recognizes an ordered-procedure structure already present in the situation. This even profile — value-neutral and partly substrate-general, but tinted by a cog-sci lexicon and origin and confined to agentic substrates — is exactly what the mixed-structural label with its 0.4 aggregate records.
Substrate Independence¶
Script is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its breadth is genuinely good: the temporally-ordered-schema-with-role-slots pattern recurs across cognitive science, service design and UX, software and automation (shell scripts, CI/CD pipelines, behavior trees), law and procedure, social interaction and ritual, robotics and embodied AI, and pedagogy. The signature is well abstracted — the four-commitment conjunction (temporal ordering, role-binding, slot-filling with defaults, breach-diagnosis) is stated structurally and carries from cognition into software, services, and robotics with little translation — and transfer is concrete: the role-slot and precondition/postcondition machinery ports wholesale from the restaurant script to customer-journey maps to CI pipelines to surgical checklists, with the breach as the shared diagnostic payload. What pins the composite to the middle is that the substrates cluster as agentic ones: a script presupposes an agent (human or AI) that recognizes a situation, binds particulars to roles, and runs a prediction against observation, so it does not reach indifferent physical or biological substrates the way percolation does. Compounding this lightly, the native lexicon is cog-sci terminology that translates with mild friction, and invoking the prime half-imports the role-slot interpretive frame. The strong, formally-instanced cross-domain transfer holds it at a 3; the agentic-substrate ceiling keeps it from climbing.
- Composite substrate independence — 3 / 5
- Domain breadth — 4 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 4 / 5
Relationships to Other Primes¶
Parents (1) — more general patterns this builds on
-
Script is a kind of Schema
The file: a script is 'the specifically temporally-and-causally ordered SCHEMA'; a schema is the generic slot-and-filler bundle that may or may not be ordered. Script inherits schema's slot machinery and adds ordered sequence + breach-on-next-step. Genus=schema (the 0.83 nearest, the correct parent).
Path to root: Script → Schema → Abstraction
Neighborhood in Abstraction Space¶
Script sits among the more crowded primes in the catalog (31st percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.
Family — Ordering, Sequencing & Dependency (12 primes)
Nearest neighbors
- Prospective Memory — 0.74
- Implementation Intention — 0.74
- Stage Gate Process — 0.72
- Sequencing — 0.72
- Compellence — 0.71
Computed from structural-signature embeddings · 2026-06-14
Not to Be Confused With¶
The defining distinction — and the embedding-nearest neighbor at similarity 0.83 — is with schema, of which a script is a specialization. A schema is the generic structured-knowledge representation: a slot-and-filler bundle that organizes what an agent knows about a kind of thing (a "room" schema with slots for walls, door, floor; a "buying" schema with buyer, seller, goods, money). Crucially, a schema need not be temporally ordered — the slots of a room schema have no "first the walls, then the floor" sequence. A script is precisely the schema that adds temporal and causal ordering: this step, then that step, each setting up the next's preconditions, with a continuously-running prediction of the next step whose violation is a breach. So a script inherits the schema's slot-and-filler machinery (its role-slots and default fillers) and adds two things the bare schema lacks: a causally-ordered sequence and the breach-diagnosis that fires when observation departs from the predicted next step. The practical consequence is sharp: schema reasoning fills in unstated attributes of a static situation ("a restaurant has tables"), while script reasoning predicts unstated events in a sequence ("she must have ordered before the food came") and flags temporal anomalies. Calling a temporally-ordered procedure "just a schema" loses the prediction-and-breach payload that is the script's entire diagnostic value; calling a static attribute-bundle a "script" wrongly imports a sequence and a breach that are not there.
A second confusion is with sequencing, invited because both involve order. But sequencing is only the order — the bare relation of one thing coming before another. A script is order plus the full apparatus: role-slots bound to different actors on each performance, default fillers that supply unstated particulars, preconditions and termination conditions that bracket applicability, and the breach operation that turns the predicted next step into a running check. An ordered list of timestamps, or the steps of a recipe with no roles to bind and no expectation to violate, is sequencing without being a script. What the script adds over sequencing is interpretive machinery: it is not merely that the steps have an order but that recognizing the situation binds particulars to roles and generates predictions whose failure is informative. Reducing a script to its sequence discards exactly the role-binding and breach-diagnosis that let it interpret novel encounters and detect anomalies.
A third confusion, especially in software where "script" is a literal artifact, is with algorithm. The two share ordered, parameterized steps, but they differ in determinism and epistemic status. An algorithm is a precise procedure that, executed correctly, is guaranteed to compute its result — its steps are exhaustively specified and its correctness is a matter of proof or definition. A script is a defeasible expectation about how a familiar situation typically unfolds: it tolerates variation, permits optional and reordered steps, supplies defaults that may be wrong, and — most distinctively — is informative precisely through its breaches, which an algorithm has no analogue of (an algorithm that "deviates" is simply buggy, not informatively anomalous). A CI pipeline blurs the line because it is authored as a deterministic algorithm yet instrumented as a script — each stage's postcondition is a breach-check, and a failed check is read as a meaningful anomaly triggering recovery, which is script reasoning layered onto algorithmic execution. The distinction matters because algorithmic thinking asks "does this compute the right answer?" while script thinking asks "did the expected sequence actually occur, and if not, what does the deviation tell me?" — and the second question is the one that makes scripts useful for interpretation and monitoring.
For a practitioner, these distinctions route the design. If the knowledge is a static attribute bundle, model it as a schema and fill in attributes. If you only need order, you need sequencing. If you need a guaranteed computation, write an algorithm. Reserve the full script apparatus — ordered steps, role-slots, defaults, and instrumented breaches — for recurring situations you must interpret, predict, and monitor, where the most valuable output is not the smooth routine but the deviation the breach makes visible.
Solution Archetypes¶
No catalogued solution archetypes reference this prime yet.