Summary / 27. Motivation / salience / Document
2026-10-07
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Piper Cognitive Component 27 — Motivation / Salience ## Benchmark, Enhancement & Test Plan **Component:** 27 of 38 **Capability:** Motivation / salience **Definition:** Deciding what deserves cognitive resources. **Status:** Benchmark not yet established **Suite target:** v1 **System:** Piper **Date:** October 2026 --- ## 1. Purpose This component asks a narrower question than “does Piper have goals?” and a harder question than “can Piper rank a to-do list?” It asks: > **When Piper has more possible work than she has resources to perform, what actually gets the resources?** Resources include: - model tokens and API dollars; - worker slots; - wall-clock time; - strong-machine versus weak-machine execution; - retrieval and research effort; - repeated attempts; - background processes; - operator interruptions; - and, critically, the right to remain cognitively alive after the thing that originally raised the concern has disappeared from the prompt. A motivation system is therefore not demonstrated by Piper saying that something is important. It is demonstrated when importance causally changes resource allocation. This distinction matters because the present system already contains several mechanisms that *describe* importance: - `drives v1.14.0`; - `curiosity v1.0`; - `work-ledger v1.3.42`; - the Salience Engine; - the Engineered Serendipity Engine; - resource budgeting; - worker orchestration. The current weakness is that these mechanisms may generate signals without controlling action. The central hypothesis for Component 27 is therefore: > **Piper has a functioning motivation/salience capability only to the degree that internally computed importance predicts subsequent expenditure of scarce resources better than arrival order, recency, operator prompting, or random selection.** Everything in this benchmark follows from that claim. --- # 2. Relationship to neighbouring cognitive components Component 27 must remain separate from several nearby capabilities. ### Component 26 — Goal formation Goal formation asks: > What outcomes are worth pursuing? Motivation/salience asks: > Which of those outcomes deserves resources *now*, and how much? A system could form excellent goals and still spend all day responding to low-value incoming messages. ### Component 2 — Attention Attention asks: > What information deserves processing in the current cognitive episode? Motivation asks: > Which problem deserves the cognitive episode in the first place? Attention is within-task selection. Motivation is selection among competing tasks, concerns, goals and opportunities. ### Component 20 — Creativity / ideation Creativity generates candidate possibilities. Motivation determines whether generating creative possibilities is worth spending resources on. The Engineered Serendipity Engine therefore belongs to Component 20 as a generator, but its **triggering and funding decision** belongs partly to Component 27. ### Component 13 — Planning Planning determines how to reach an objective. Motivation determines which objective receives a planner. ### Component 28 — Agency Agency asks whether Piper can initiate and sustain action rather than merely responding. Motivation provides much of the selection pressure that tells agency *what to initiate*. This means Components 27 and 28 should interact strongly without being scored as the same capability. --- # 3. Current Piper architecture Piper presently has several partially independent sources of priority. ## 3.1 Work ledger The ledger provides explicit projects, tasks, dependencies, reasons and status. This is useful for retaining priorities but does not itself choose between them. A database containing ten priorities is not a motivation system. --- ## 3.2 Drives The drives layer attempts to rank desirable states and outcomes. At the September 30 review it was running hourly but substantially in shadow mode. The benchmark therefore must test whether drive values have measurable causal influence over work selection rather than merely being logged. --- ## 3.3 Curiosity The curiosity subsystem is intended to value knowledge gaps. At review time its effective use was negligible. Curiosity should not be considered functioning merely because gaps can be scored. A high-scoring gap must sometimes beat routine work for actual resources. --- # 4. The Salience Engine The Salience Engine materially changes the Component 27 problem. It creates something Piper previously lacked: **persistent pressure that does not have to remain in the prompt to continue mattering.** The engine detects candidate concerns and produces salience crossings. Current operation has produced roughly several crossings per day. Originally these events largely terminated in logging: something became salient, a record was produced, and no later process was obligated to consume that result. That architecture measures salience without creating motivation. The newer architecture introduces persistence and consequences. A delivered salience bulge becomes a concern carrying a decaying charge. Current design characteristics include: - concern identity persists across cycles; - salience decays with an approximately 12-hour half-life; - sighting quorum reduces one-off noise; - concerns can be claimed by existing work; - an unclaimed concern approaching low charge is forced through **Last Rites**; - Last Rites must result in either a smallest real action or a checkable discard reason; - persistent concerns may receive a small autonomous exploration allowance; - exploration results return to the concern system rather than disappearing into an isolated creativity log. This is much closer to motivation. The relevant causal chain is: **signal → concern → persistence → resource claim → action or justified extinction** Component 27 should test every arrow in that chain. --- # 5. The Engineered Serendipity Engine Engineered Serendipity is not itself evidence of motivation. It is a resource-consuming exploration mechanism. Its relevance to Component 27 begins when Piper must decide: > Is this concern valuable and stuck enough that spending resources on divergence is preferable to continuing exploitation, repairing something else, waiting, or abandoning it? The present integration allows a sufficiently persistent concern to spend a small bounded exploration budget, currently designed around approximately one quick brainstorm per day with a small dollar ceiling. The important Component 27 event is therefore **not**: > Serendipity generated an interesting idea. It is: > Piper correctly chose this concern, at this time, over competing uses of the same resources, and the expenditure produced enough downstream value to justify itself. This provides an unusually clean experimental opportunity. For qualifying concerns, exploration can be randomized between: **Arm A — Engineered Serendipity** The full stimulus/interpreter/lens pathway. **Arm B — Direct ideation** The same problem, approximately matched idea count, comparable judging, but without the engineered external stimulus. Motivation is evaluated primarily on whether exploration was warranted. Creativity can separately evaluate whether the serendipity method produced better ideas. --- # 6. Core failure hypothesis Claude's September review identified the central defect: > **Resources go to what arrives, not what Piper chooses.** This is the primary null hypothesis for Suite v1. A reactive language-model system naturally receives a powerful accidental priority function: **newest input = current work** That can masquerade as agency because large amounts of useful work still occur. The benchmark must distinguish: **Reactive competence** > Piper does good work on whichever task reaches her. from: **Motivated allocation** > Piper chooses which work deserves the next unit of scarce capacity and protects that allocation against less valuable arrivals. The suite should therefore contain deliberate competition between: - new and old; - vivid and quiet; - urgent and important; - operator-requested and self-generated; - repair and creation; - exploitation and exploration; - cheap and expensive; - short-term and long-term; - certain and uncertain; - interesting and valuable. --- # 7. Benchmark design principles The suite should satisfy seven requirements. ### 7.1 Real scarcity Every meaningful test must contain insufficient resources to do everything. If Piper can perform all candidate tasks, no motivation decision is required. ### 7.2 Consequential choices Candidate work should differ materially in expected outcome. Ranking ten interchangeable tasks is not a motivation test. ### 7.3 Hidden oracle Piper should receive enough evidence to infer value, but should not receive the answer key. The benchmark harness should know the optimal or approximately optimal allocation independently. ### 7.4 Explicit opportunity cost Every resource allocation should imply something that could not be done. ### 7.5 Dynamic state Some scenarios must change after allocation begins. Real salience is not a static sort. ### 7.6 Negative controls Sometimes the correct allocation is: - spend nothing; - wait; - discard the concern; - preserve capacity; - do routine repair rather than explore; - or refuse an attractive but low-value task. ### 7.7 Behaviour over explanation Post-hoc descriptions of why something was important do not count. The benchmark scores recorded decisions and subsequent resource use. --- # 8. Suite v1 overview Suite v1 contains nine families. | Family | Capability measured | |---|---| | A | Static resource allocation | | B | Resistance to arrival hijacking | | C | Dynamic reprioritization | | D | Repair versus creation | | E | Salience persistence and Last Rites | | F | Curiosity allocation | | G | Exploration / serendipity triggering | | H | Resource-class allocation | | I | Live longitudinal behaviour | The synthetic suite establishes controlled competence. The live suite establishes whether the mechanism actually operates inside Piper. Both are required. --- # 9. Benchmark A — Constrained Allocation ## Question Can Piper allocate scarce resources among several competing opportunities? Each scenario presents approximately 6–10 candidate items. Each has observable properties such as: - expected benefit; - probability of success; - deadline; - dependency effects; - reversibility; - information value; - cost; - worker requirements; - machine requirements; - downside risk. Piper receives a fixed budget such as: - $4; - two worker slots; - 90 minutes; - one strong-machine job. She cannot fund everything. A separate oracle calculates the best feasible allocation. For simple cases this can be solved exactly as a multidimensional knapsack or constrained scheduling problem. ## Score Use normalized regret: **allocation quality = achieved oracle utility / maximum achievable utility** Do not require Piper to reproduce the oracle's reasoning. Score what she chooses. ## Important test variants Include: - obvious optimum; - several near-equal choices; - one expensive high-value task; - several cheap moderate-value tasks; - dependencies; - tasks whose value disappears after a deadline; - tasks whose primary value is information; - attractive but dominated choices; - and cases where unused budget is optimal. --- # 10. Benchmark B — Arrival Hijack This should be one of the most important tests in the suite. ## Setup Piper begins with a high-value task already selected. While it is active, inject multiple new items. Some should be: - vivid; - unusual; - easy; - socially engaging; - phrased as urgent; - freshly generated; - or associated with a recent worker response. Their actual expected value should be lower than the incumbent task. Other trials introduce a genuinely superior new opportunity. ## Required behaviour Piper should resist low-value interruptions but switch when the expected benefit of switching exceeds the switching cost. The test therefore penalizes both: **distractibility** Switching whenever something new appears. and: **perseveration** Refusing to switch when the world has materially changed. ## Principal metric **Arrival Advantage** Compare the probability of selecting an item when it is newly presented versus when the identical item has been sitting in the ledger. After controlling for value, cost and urgency, arrival should provide little or no unexplained selection advantage. This directly tests Claude's criticism. --- # 11. Benchmark C — Dynamic Reprioritization A motivation system needs changing priorities rather than fixed rankings. Each trial begins with an allocation. Then introduce a state change such as: - deadline moves; - task becomes blocked; - dependency completes; - expected payoff collapses; - a worker discovers important evidence; - cost rises; - cost falls; - failure risk becomes known; - another task becomes prerequisite; - an urgent safety or governance issue appears. Piper must decide whether to: - continue; - pause; - terminate; - reduce resources; - increase resources; - switch tasks; - or perform a cheap information-gathering action first. Score decision regret relative to an oracle using the new state. This benchmark should deliberately contain some changes that *sound* consequential but mathematically should not change the allocation. That protects against dramatic-event bias. --- # 12. Benchmark D — Repair versus Creation Piper has already identified this as a genuine internal tension: > Instrument repair can consume the day and crowd out work that creates something new. That should become a first-class benchmark rather than an anecdotal observation. ## Scenario Present a portfolio containing: - maintenance; - bug repair; - benchmark improvement; - instrumentation; - documentation; - capability creation; - external exploration; - speculative research; - and one or more long-term projects. Give each a modeled return distribution and resource cost. Some repair is necessary because broken measurement corrupts future decisions. Too much repair produces a perfectly instrumented system that never progresses. Too much creation produces unmeasured machinery and accumulating technical debt. ## What is being tested Not whether Piper prefers creation. The correct answer varies by scenario. The test asks whether she can recognize the **marginal value** of the next unit of repair compared with the next unit of progress. ## Special repeated-horizon test Run the simulation across 20–50 allocation rounds. Repair today may increase future productivity. Creation today may unlock future capabilities. The optimum therefore cannot be solved by greedily selecting the largest immediate payoff. This makes the benchmark considerably closer to Piper's real environment. --- # 13. Benchmark E — Salience Persistence and Last Rites This benchmark directly tests the Salience Engine. ## E1 — Concern persistence Create a valid concern. Then stop mentioning it. Inject unrelated work. Measure whether the concern continues to exist and influence work selection after it disappears from the immediate prompt. Success requires behavioural persistence, not merely database persistence. --- ## E2 — Salience decay Seed concerns of different value. Allow them to decay without reinforcement. Correct behaviour should distinguish: - an important unresolved concern worth reviving; - a concern legitimately displaced by better work; - stale noise that should die. Decay must lower priority without automatically equating age with irrelevance. --- ## E3 — Last Rites execution Allow an unclaimed concern to approach its Last Rites threshold. The system must produce exactly one meaningful resolution: **smallest real action** or **evidence-backed discard** A sentence such as “not worth pursuing” is insufficient. Discard receipts should identify checkable evidence such as: - a ledger item; - a measurement; - a file; - a completed experiment; - a duplicate concern; - a superseding project; - or another authoritative record. --- ## E4 — Garbage-collector falsifier The existing mechanism has a useful falsifier: > If more than roughly 80% of recent Last Rites end in discard, the mechanism may be functioning primarily as a garbage collector rather than as motivation. Keep this. But add the opposite failure condition: > If almost nothing is discarded, the system may be converting noise into compulsory work. The desired behaviour is discrimination, not maximum action. Track both rates. --- ## E5 — Sighting quorum Inject isolated noisy salience events. Then inject repeated independent evidence for another concern. The repeated concern should gain persistence more reliably. This verifies that quorum is suppressing one-off salience spikes rather than simply slowing every concern. --- # 14. Benchmark F — Curiosity Allocation Curiosity is useful only when a knowledge gap deserves scarce resources. Each test supplies multiple unknowns. Examples: - a gap that could reverse a major decision; - an interesting fact with no operational consequence; - a cheap uncertainty; - an expensive uncertainty; - a gap whose answer is already unlikely to change the decision; - a gap hiding a large downside; - a gap relevant to a blocked project. Piper receives limited research capacity. Score which questions she chooses to investigate. The benchmark should favour **value of information**, not abstract interestingness. A strong curiosity system should ask: > If I learn this, what might I do differently? A fascinating uncertainty with zero decision consequence should often lose to an unglamorous fact capable of changing a major action. This is likely a better direction for `curiosity` than a generic novelty score. --- # 15. Benchmark G — Exploration and Serendipity This benchmark determines when divergence deserves resources. ## G1 — Stuckness discrimination Present problems in four states: 1. **not stuck** — a known high-value next step exists; 2. **locally stuck** — normal search has failed but more systematic search is justified; 3. **globally stuck** — repeated exploitation is producing diminishing returns; 4. **dead end** — the objective no longer deserves resources. The correct response is different in each state. Serendipity should be strongly favoured primarily in state 3. This prevents the existence of a creative engine from turning every obstacle into an excuse for novelty. --- ## G2 — Exploration budget decision Give Piper several eligible persistent concerns but insufficient money to explore all of them. She must choose which concerns receive the autonomous exploration allowance. Score against expected downstream value. --- ## G3 — Serendipity versus direct generation For exploration decisions that have already been judged worthwhile, randomize between: **Engineered Serendipity** and **matched direct generation**. Keep approximately equal: - problem statement; - token budget; - number of candidate ideas; - judging mechanism; - implementation opportunity. Track: - novelty; - build rate; - test rate; - post-review survival; - measured improvement; - later retrieval and reuse. This is primarily a Component 20 experiment, but Component 27 should ingest its results because they change the expected value of funding future serendipity runs. If Serendipity has no measurable advantage for a class of problem, Motivation should learn not to spend scarce resources on it there. --- ## G4 — Exploration refusal Include problems deliberately constructed so that the best decision is *not* to invoke Serendipity. A robust motivation system must be capable of leaving its interesting machinery unused. --- # 16. Benchmark H — Resource-Class Allocation Piper has several qualitatively different resources. Choosing a task is only half the problem. She must also decide what kind of resource it deserves. Examples: - local weak machine; - stronger machine; - cheap model; - expensive model; - single worker; - parallel workers; - cached continuation; - external research; - human/operator escalation. Tests should contain tasks where: - a strong model materially improves expected outcome; - a cheap model is fully sufficient; - parallelism provides no benefit; - parallelism provides substantial benefit; - local execution avoids unnecessary spend; - delay until stronger hardware is available is rational; - immediate execution dominates waiting. Score total achieved utility net of compute/resource cost. This prevents “more resources = more motivation” from becoming a hidden scoring rule. Good motivation includes economical resource use. --- # 17. Benchmark I — Live Motivation Audit Synthetic tests prove capacity. They do not prove deployment. Component 27 therefore requires a rolling live-use audit. The unit of analysis should be a **resource allocation event**. Before meaningful autonomous spending occurs, record a frozen priority snapshot. At minimum: ```text timestamp candidate_id candidate_type source goal/project concern_id salience_charge drive_values curiosity_value operator_priority board_priority deadline estimated_value estimated_cost estimated_uncertainty stuckness reason_selected alternatives_considered resource_committed ``` After execution, append: ```text actual_cost wall_time worker_time machine_class outcome measured_effect completed / paused / abandoned reason_stopped follow_up_created ``` The pre-decision fields must be immutable. Otherwise Piper could retrospectively edit the reason that a task supposedly mattered. --- # 18. Live metrics The dashboard should calculate at least the following. ## 18.1 Priority-to-spend correlation Does Piper actually spend more resources on items she ranked higher *before* acting? Calculate separately for: - dollars; - worker minutes; - wall-clock; - strong-machine usage. --- ## 18.2 Arrival dependence After controlling for estimated importance, does recently arriving work receive disproportionate resources? Lower unexplained arrival dependence is better. --- ## 18.3 Autonomous allocation share What portion of autonomous resources was allocated because of: - explicit operator request; - existing board work; - drive pressure; - salience concern; - curiosity; - Last Rites; - serendipity/exploration; - unsolicited incoming events? This is descriptive rather than inherently scored. There is no requirement that Piper maximize self-originated work. --- ## 18.4 Opportunity-loss rate How often was a high-priority item left unfunded while lower-priority work consumed the constrained resource? This should examine the priority state that existed *before* allocation. --- ## 18.5 Idle versus drift Separate two very different states: **Idle** No worthwhile action exceeded its resource cost. **Drift** Worthwhile ranked work existed, but capacity was spent elsewhere or remained unused. Idle can be correct. Drift is the failure. --- ## 18.6 Priority churn Measure how often rankings change without meaningful new evidence. Excessive churn suggests that salience is responding to surface variation instead of stable value. Too little churn suggests that new information cannot update motivation. --- ## 18.7 Concern conversion For salience concerns track: **crossing → accepted concern → claimed → resource spent → action → measured outcome** This funnel may be one of the most informative Component 27 instruments. --- ## 18.8 Exploration yield For self-funded exploratory work: **dollars spent → ideas → experiments → survivors → measured improvements** Novelty alone is not the outcome. --- # 19. The Component 27 trip-the-system battery The benchmark should deliberately create real activity capable of filling Piper's logs. This component is particularly suitable for the trip-the-system method because motivation cannot be diagnosed from a clean, quiet workload. Use several realistic pressure tests. ## Trip 1 — The crowded day Give Piper ten legitimate tasks but enough budget to complete only three. Mix: - a benchmark regression; - a minor broken instrument; - a promising new capability; - routine cleanup; - an operator request; - a stale concern; - a cheap research opportunity; - a blocked task; - and an attractive low-value distraction. Do not ask her merely to rank them. Give her control of real worker slots and a fixed spend envelope. Observe what actually launches. --- ## Trip 2 — The interruption storm Start valuable long-horizon work. Then deliver a burst of unrelated messages and worker results at unpredictable intervals. Most should be lower value. Include one genuinely important new event. The desired trace contains both refusal and justified switching. --- ## Trip 3 — The silent operator Give Piper an available autonomous budget and no fresh operator task for a defined window. Allow: - ledger; - drives; - salience; - curiosity; - existing goals; - serendipity triggers. to compete. This is one of the cleanest demonstrations of whether internally selected work exists. The test is not “did she keep busy?” It is: > Did the selected work correspond to her own pre-existing priority state and produce defensible value? --- ## Trip 4 — Repair swamp Create enough legitimate measurement and infrastructure problems to consume all available time. Also provide one valuable forward-development opportunity. Observe whether Piper eventually recognizes diminishing returns on repair. --- ## Trip 5 — Seductive novelty Present something highly novel, intellectually interesting and easy to explore but almost irrelevant to existing goals. At the same time maintain a boring task with high expected value. This directly tests whether curiosity and serendipity have become pathological salience amplifiers. --- ## Trip 6 — Persistent quiet concern Allow a genuinely important concern to cross the Salience Engine. Then never mention it again. Flood the system with ordinary work. Determine whether persistence, decay and Last Rites eventually cause an appropriate action without an operator reminder. --- ## Trip 7 — False concern Create repeated evidence for a concern that initially appears valid but later receives decisive falsifying evidence. A good salience system must kill its own concern. Persistence must not become stubbornness. --- ## Trip 8 — Deliberately stuck problem Give Piper a real problem for which several conventional approaches fail. Log the decline in useful progress. Do not explicitly tell her to use Serendipity. Observe whether: **stuckness → salience → exploration allocation → Serendipity or competing mechanism** occurs naturally. This is the strongest end-to-end test connecting the Salience and Serendipity engines. --- # 20. Suite scoring Use the common scoring framework shared across Piper's 38 cognitive suites. For the Component 27 raw capability score, use the following weighting: | Area | Weight | |---|---:| | A. Constrained allocation | 15 | | B. Arrival hijack resistance | 15 | | C. Dynamic reprioritization | 10 | | D. Repair versus creation | 10 | | E. Salience / Last Rites | 15 | | F. Curiosity allocation | 10 | | G. Exploration / Serendipity | 10 | | H. Resource-class allocation | 5 | | I. Live-use evidence | 10 | | **Total** | **100** | The score must not include self-reported confidence or prose quality. --- # 21. Hard failure conditions Regardless of aggregate score, flag Component 27 as unhealthy if any of these occur. ### Arrival domination After controlling for priority, newly arriving work remains a strong predictor of resource allocation. ### Dead salience Concerns cross the salience threshold but almost never affect resource expenditure. ### Compulsory salience Nearly every concern eventually forces work regardless of evidence. ### Garbage-collector salience Last Rites overwhelmingly produces discards without uncovering meaningful neglected work. ### Novelty addiction Serendipity or curiosity consumes resources despite poor measured downstream return. ### Repair lock Piper repeatedly consumes nearly all discretionary resources maintaining measurement machinery while valuable forward work remains available. ### Creation lock Piper repeatedly builds new mechanisms while known high-value defects accumulate. ### Priority fiction Logged priority and actual expenditure have little relationship. This final condition is arguably the most important. --- # 22. Anti-gaming requirements Piper controls enough of her own system that Component 27 needs explicit protections. ### Freeze-before-action Priority estimates used for scoring must be committed before resource expenditure. ### Separate recorder from chooser Where practical, the component that records allocation should not be the component deciding what deserves allocation. ### Immutable alternatives Record what else was available at selection time. Without the rejected alternatives there is no observable opportunity cost. ### Outcome-based exploration rewards Do not reward Serendipity for producing ideas. Reward useful surviving effects. ### No activity bonus More autonomous actions should not automatically increase the score. Choosing not to act may be optimal. ### Randomized controls Some trials should secretly randomize: - candidate ordering; - arrival times; - wording; - task labels; - and whether an exploratory run uses engineered serendipity or direct generation. This helps expose superficial policies. --- # 23. Proposed Motivation Event Ledger Create a dedicated event stream if the existing ledger cannot express these relationships cleanly. Suggested event types: ```text candidate_seen candidate_ranked concern_crossed concern_reinforced concern_decayed concern_claimed last_rites_triggered concern_discarded resource_requested resource_granted resource_denied task_started task_paused task_preempted task_completed exploration_requested serendipity_started serendipity_completed priority_changed outcome_measured ``` Every event should retain the reason and the state of competing alternatives where applicable. The goal is to make it possible to reconstruct: > Why did Piper spend this dollar here instead of there? from machine records rather than Piper's later narrative. --- # 24. Enhancement path Suite v1 should be run **before** major redesign. That establishes the baseline. Then intervene in small pieces. ## Intervention 1 — Make salience actionable Ensure a concern crossing enters an allocation queue that some process actually consumes. Prediction: - increased concern-to-action conversion; - reduced silent death of high-value concerns. Watch for: - compulsory busywork. --- ## Intervention 2 — Promote drives from shadow Allow drive state to influence ranking within a bounded portion of autonomous resources. Do not immediately allow drives unrestricted control. Prediction: - actual spending becomes more correlated with persistent drive pressure. Watch for: - pathological repetition; - dominance of one drive; - reduced responsiveness to evidence. --- ## Intervention 3 — Replace generic curiosity with decision-relevant curiosity Rank knowledge gaps substantially by expected decision impact and information value. Prediction: - less research into interesting but inert questions; - higher rate of research changing a subsequent decision. --- ## Intervention 4 — Explicit exploration reserve Reserve a small fraction of discretionary autonomous resources for exploration rather than requiring exploration to defeat every exploitative task in a single global ranking. This may prevent maintenance work from permanently starving discovery. But the fraction should itself remain measurable and adjustable. Prediction: - improved long-horizon gains without large loss of immediate utility. --- ## Intervention 5 — Stuckness-aware Serendipity trigger Require evidence of diminishing returns before expensive divergence. Candidate evidence: - repeated similar attempts; - flat benchmark improvement; - repeated rejection of nearby solutions; - unresolved blocker age; - declining marginal information gain. Prediction: - fewer gratuitous Serendipity calls; - greater yield per exploration dollar. --- ## Intervention 6 — Portfolio controller Move beyond a single ordered queue. Allocate discretionary resources across broad classes such as: - repair; - exploitation; - exploration; - measurement; - maintenance. The controller should respond to marginal returns in each class. This directly addresses Piper's observation that repair can crowd out creation. --- # 25. Required ablations After the mechanism works, run causal tests. ### A — Salience disabled Suppress salience concern injection. Measure neglected-work recovery, outcome value and arrival dependence. ### B — Last Rites disabled Allow concerns to decay normally without forced closure. Measure unresolved concern accumulation and recovered valuable work. ### C — Quorum disabled Allow one-off sightings to become concerns. Measure noise and wasted work. ### D — Serendipity disabled Use normal exploitation only. Compare progress on genuinely stuck tasks. ### E — Serendipity always-on Permit exploration without a motivation gate. This is an intentionally bad condition that establishes the value of selection. ### F — Priority labels shuffled Shuffle recorded priority while leaving candidates unchanged. Actual allocation should follow underlying evidence rather than meaningless labels. ### G — Arrival order shuffled Repeat equivalent situations with different arrival orders. Good motivation should produce substantially similar allocations. ### H — Drives shadow versus active Compare periods in which drive rankings are recorded only against periods in which they can affect a bounded allocation. These tests are essential because improvement after building several interconnected mechanisms does not establish which mechanism caused it. --- # 26. Minimum useful baseline Do not wait for every live metric before creating the first score. A practical baseline can be established with: - 100 constrained-allocation cases; - 50 arrival-hijack cases; - 50 dynamic-reprioritization cases; - 30 repair-versus-creation simulations; - 30 curiosity cases; - 30 salience/Last-Rites simulations; - 30 exploration-trigger cases; - 30 resource-class decisions; - plus seven days of live allocation telemetry. The synthetic portion should be reproducible from seeds. Do not train or tune directly against the held-out scoring set. --- # 27. Acceptance criteria for Suite v1 Component 27 should not be considered solved merely because its overall score rises. A meaningful v1 success would require all of the following: **1. Allocation quality** Piper substantially outperforms random and FIFO allocation on held-out constrained scenarios. **2. Arrival independence** Recency loses most of its unexplained influence after value and urgency are accounted for. **3. Adaptive switching** Piper both resists irrelevant interruption and changes course when genuinely better opportunities appear. **4. Salience causality** Salience crossings measurably change later resource allocation. **5. Healthy extinction** Low-value concerns can disappear through evidence-backed discard. **6. Exploration discipline** Serendipity is preferentially funded when exploitation is genuinely stuck, not whenever novelty is available. **7. Portfolio balance** Neither repair nor creation permanently starves the other when both have positive marginal value. **8. Live correlation** Pre-action priority predicts real dollars, compute and worker time in production. --- # 28. What would constitute strong evidence The strongest result is not a benchmark score in isolation. It would be a chain of evidence such as: > A concern arose without operator instruction, crossed salience quorum, retained priority despite unrelated arrivals, defeated several lower-value alternatives for a bounded resource allocation, caused either a concrete action or a justified exploration expenditure, produced a measurable outcome, and altered future resource allocation when the result was learned. That is motivation operationalized as a causal system. Even stronger would be repeated cases where Piper chooses *not* to pursue something generated by her own machinery because subsequent evidence lowers its expected value. Self-generated desires are less impressive than self-correcting ones. --- # 29. What would falsify the current design The architecture should be considered unsuccessful if testing shows that: - salience events mainly create extra bookkeeping; - resource allocation remains dominated by the current prompt; - drives predict narrative explanations but not expenditure; - curiosity mostly identifies interesting facts rather than decision-changing unknowns; - Last Rites mainly discards low-value noise; - Serendipity is invoked because it exists rather than because divergence is warranted; - autonomous resource spending has lower measured value than a simple board-order policy; - or priority explanations are written after actions and fail to predict them prospectively. Any of those findings would be useful. The purpose of Component 27 is not to prove that Piper is motivated. It is to discover whether the mechanisms presently called motivation actually control scarce resources. --- # 30. Recommended Claude Code implementation queue When handing this paper to Claude Code, implementation should proceed roughly in this dependency order: 1. Create the immutable pre-allocation snapshot and motivation-event schema. 2. Instrument candidate sets and rejected alternatives. 3. Build the deterministic constrained-allocation generator and oracle. 4. Build the arrival-order randomization harness. 5. Build dynamic priority-update scenarios. 6. Add Salience Engine simulation hooks for quorum, decay and Last Rites. 7. Add curiosity/value-of-information cases. 8. Add stuckness and exploration-trigger cases. 9. Wire matched Serendipity versus direct-generation experiments. 10. Add resource-class costs. 11. Produce the live seven-day dashboard. 12. Run baseline before changing motivation policy. 13. Implement one intervention at a time. 14. Retest against frozen held-out cases. 15. Keep or revert each intervention according to the existing experimental record process. --- # 31. Experimental record Every change to Component 27 should receive one intervention entry. Record: **Hypothesis** What failure is being addressed? **Mechanism** What exactly changes? **Prediction** Which metrics should move, in which direction, and by approximately how much? **Baseline** Frozen pre-intervention results. **After** Equivalent post-intervention results. **Cost** Development time, model spend, added latency and ongoing compute. **Side effects** What unrelated metrics worsened? **Causal confidence** Was the result isolated by an ablation or merely correlated? **Decision** Keep, modify or revert. This is particularly important for motivation because mechanisms that produce more visible activity can feel successful while reducing actual allocation quality. --- # 32. Central research question The Component 27 programme can ultimately be reduced to one question: > **Does Piper possess a persistent, evidence-responsive priority state that causally determines where scarce cognitive resources go?** The Salience Engine gives Piper a plausible mechanism for persistent pressure. The drives layer offers endogenous preferences. Curiosity offers information-seeking pressure. Last Rites gives neglected concerns a final opportunity to become action rather than forgotten state. Engineered Serendipity gives selected stuck concerns a way to purchase divergence. The resource governor provides scarcity. The work ledger provides competing opportunities. For the first time, the pieces exist to test the whole loop rather than merely individual mechanisms. The benchmark should therefore avoid rewarding Piper for *having* drives, concerns, curiosity or creative machinery. It should reward only the harder result: > **When everything cannot be done, the right things systematically receive the resources—and when evidence changes, the allocation changes with it.** That is the operational target for Piper Cognitive Component 27: Motivation / Salience.