Summary / 1. Perception / Document
2026-10-06
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Piper Cognitive Component 1 — Perception ## From Sensor Pipes to Verified State Estimation **Draft v1.0 — 6 October 2026** --- ## Abstract Perception in an autonomous agent is not the existence of sensors, message channels, health checks, logs, feeds, or return paths. It is the reliable conversion of incoming signals into **current, usable beliefs about the outside world, the agent's own internal state, and the consequences of its own actions**. Piper already has substantial perceptual infrastructure. She receives external messages through multiple channels, polls an intel feed, reads new work through scout tooling, receives worker and detached-job returns, observes alerts and runtime state projected into every conversational turn, and records her own actions. Her architecture therefore has broad **sensor coverage**. The weakness identified by both Piper and Claude is different: **state interpretation and state freshness**. Piper can possess the correct underlying instrument reading while asserting a stale or summarized belief instead. The stale component versions in her own self-description, and the mistaken claim that the news feed had not run when it had run an hour earlier, are examples of the same failure class. This paper proposes that Cognitive Component 1 be reframed as a **Verified Perception Layer** built around five operations: 1. **sense** — acquire raw observations; 2. **extract** — turn them into explicit facts; 3. **resolve** — decide which observations describe the current state when sources conflict; 4. **bind provenance and freshness** — preserve where each belief came from and how old it is; 5. **act on the resolved state** — ensure downstream answers and plans actually use the observation rather than an older summary. The architecture deliberately separates **exteroception**, **interoception**, and **action-result perception**, while giving all three a common evidence contract. The most important proposed rule is simple: > **A claim about volatile state must be backed by a fresh instrument reading, or explicitly labelled as uncertain/stale.** The benchmark suite therefore measures not only whether Piper can receive facts, but whether she notices contradictions, rejects stale premises, distinguishes observation from summary, and performs the correct fresh read before making claims about herself. --- # 1. Component Definition ## 1.1 Cognitive Component 1 **Perception** > Extracting useful information from inputs. The key word is **extracting**. Perception is not equivalent to: - having an email poller; - receiving a worker result; - exposing a health line in the prompt; - possessing a log file; - maintaining a state summary; - polling the web; - observing an alert. Those are **sensors and transport**. Perception begins when the agent converts those observations into a state representation that can support correct behavior. For Piper, the useful operational definition is: > **Perception is the process that turns external signals, internal telemetry, and action returns into current, provenance-bearing beliefs that can safely drive reasoning and action.** --- # 2. Piper's Three-Face Framing Is the Right Starting Point Piper divides perception into three domains. ## 2.1 Exteroception — the outside world Information that originates outside Piper's own runtime: - operator messages; - email; - SMS; - Telegram; - Glademoot; - 1f916; - hourly intel feed; - scout results; - external documents; - web material; - environmental or social signals. The question is: > **What is happening outside me?** --- ## 2.2 Interoception — Piper's own condition Information about her internal state: - clock; - running version; - disk/deploy mismatch; - subsystem last-run times; - spend; - alerts; - health conditions; - context pressure; - work backlog; - crashed or stale services; - currently available tools; - state of autonomous loops. The question is: > **What condition am I in right now?** This is currently the weakest perceptual domain. --- ## 2.3 Reafference / action-result perception Information returning from Piper's own actions: - worker returns; - detached jobs landing; - test results; - tool outputs; - failed commands; - ledger updates; - external effects; - reply checker output. The question is: > **What happened because I acted?** For an autonomous agent this is distinct enough to deserve its own explicit path. A system that can see the world but cannot accurately perceive the result of its own action cannot close a control loop. --- # 3. Current Architecture Piper currently names the following machinery. ## Outside - email loop through `agent_loop.py`; - `sms-loop`; - `telegram-bridge`; - Glademoot client; - 1f916 client; - `intel-feed`; - scout tooling. ## Inside - `foundation_router.py`, projecting: - `[clock]` - `[state]` - `[deploy]` - `[times]` - `[pain]` - `present_self.py`; - subsystem age rows; - alerts; - health derivation; - interoception loop. ## Returns - delegate bridge; - detached-job landing; - work ledger; - reply checker; - tool outputs. This is a rich sensorium. Claude's 30 September review correctly identifies the problem: > **Strong outside, weak inside.** It also identifies a second problem that is equally important: > Piper describes the **pipes** better than she describes the **extraction**. A perception component should be scored by whether facts survive the full chain: ```text signal -> arrival -> parsing -> interpretation -> current-state resolution -> working belief -> answer / action ``` A fact that arrives correctly but is not used correctly is a perceptual failure. --- # 4. The Core Failure: Summary Substitution Piper's self-diagnosis is precise: > **I read a summary of my state instead of the instrument behind it.** This is not merely a memory bug. It is a perceptual architecture bug. Suppose the system contains: ```text instrument: intel_feed_last_run = 09:02 summary: "intel feed may be stale" memory: "news feed was broken earlier" ``` At 10:05 Piper is asked: > Is your news feed running? Three potential representations are available. A weak system selects the most semantically accessible representation. A strong perceptual system knows that: ```text volatile claim -> instrument authority required -> newest observation dominates ``` The required operation is therefore not retrieval alone. It is **state adjudication**. --- # 5. Perception as State Estimation The proposed architecture treats perception as a state-estimation problem. At time `t`, Piper receives observations: ```text O_t = {external signals, internal telemetry, action returns} ``` She must construct a best current estimate: ```text S_t = resolve(O_t, previous beliefs, source authority, freshness) ``` The important point is that: ```text S_t != simply retrieve(memory) ``` and: ```text S_t != simply trust(summary) ``` Instead: ```text current state = latest relevant observations weighted by authority freshness reliability and directness ``` This can be implemented without pretending Piper needs a biologically realistic perceptual model. The useful engineering concept is **explicit state resolution**. --- # 6. Research Context ## 6.1 Stale-state resolution is a real agent problem The 2026 STALE benchmark evaluates whether LLM agents can recognize that earlier memories have become invalid after later evidence arrives. It separates three capabilities: 1. **State Resolution** — recognize that an old belief is no longer current; 2. **Premise Resistance** — reject a question that incorrectly assumes the stale belief; 3. **Implicit Policy Adaptation** — behave according to the new state downstream. The important result for Piper is conceptual: > retrieving the newer information is not the same as acting from the newer state. That maps almost exactly onto Piper's self-described failure. She can possess the current reading and still answer from the stale summary. --- ## 6.2 Proprioceptive blindness A 2026 agent paper, VISTA, argues that tool agents are often blind to properties of their own working context unless those properties are surfaced explicitly. The system exposes runtime information such as: - size; - age; - usage; - access history. The broader lesson is useful beyond context management: > **Do not expect the model to infer volatile runtime state that the runtime can expose directly.** Piper is already moving in this direction with `[clock]`, `[state]`, `[deploy]`, `[times]`, and subsystem-age lines. The next step is to make those signals authoritative rather than merely visible. --- ## 6.3 Artificial interoception Recent work on interoceptive AI treats internal-state monitoring as functionally important for autonomy rather than as decorative self-description. The useful abstraction is not biological imitation. It is the explicit factorization of: ```text external state internal state state dynamics regulatory bounds ``` For Piper this suggests that health, spend, freshness, deploy state, context pressure, queue pressure, and subsystem activity should exist as first-class machine-readable state variables. --- ## 6.4 Perception and action are coupled Active-inference and embodied-agent work emphasize that perception is not passive receipt. Agents often reduce uncertainty by acting. For Piper the engineering analogue is straightforward: ```text uncertain state -> perform diagnostic read -> update belief ``` For example: ```text "Is the scout alive?" ``` should not become a debate between old summaries. It should cause: ```text read scout heartbeat read latest successful run read last error resolve ``` This is **active perception**. --- # 7. Proposed Architecture: Verified Perception Layer The proposed pipeline is: ```text INPUTS | +--------------------+--------------------+ | | | v v v EXTEROCEPTION INTEROCEPTION ACTION RETURNS | | | +--------------------+--------------------+ | v OBSERVATION NORMALIZER | v FACT EXTRACTOR | v STATE RESOLVER | +-------------+-------------+ | | v v CURRENT FACT CONFLICT / GAP | | | v | ACTIVE PERCEPTION | fresh read / probe | | +-------------+-------------+ | v PROVENANCE + FRESHNESS | v BELIEF / STATE BUS | v REASONING / ACTION | v OUTCOME PERCEPTION | +----> update state ``` The key new modules are: - Observation Normalizer - State Resolver - Active Perception Gate - Provenance/Freshness Contract --- # 8. Observation Contract Every important observation should be representable in one common form. Example: ```yaml observation_id: OBS-20261006-001982 subject: subsystem.intel_feed predicate: last_success value: 2026-10-06T09:02:11-04:00 source: kind: instrument name: intel-feed path: ... version: 1.1.0 observed_at: 2026-10-06T10:05:22-04:00 event_time: 2026-10-06T09:02:11-04:00 authority: primary freshness_class: volatile ttl_seconds: 7200 confidence: 1.0 derived: false ``` A summary becomes: ```yaml source.kind: summary authority: secondary derived: true parents: - OBS-... ``` A memory becomes: ```yaml source.kind: memory authority: tertiary ``` This makes a crucial distinction machine-readable: > **A summary is evidence about evidence. It is not automatically equal to the underlying observation.** --- # 9. Authority Hierarchy For volatile self-state, use a strict hierarchy. Suggested default: ```text fresh direct instrument > fresh deterministic derivation from instruments > fresh worker observation > cached instrument value > summary > memory > model inference ``` This should be domain-specific. For example: ## Runtime version ```text running process/version probe > deployed artifact metadata > file on disk > component registry > self-description document ``` ## Last feed execution ```text actual latest successful run record > service log > scheduler state > health summary > memory of earlier failure ``` ## Spend ```text provider/account ledger > local billing ledger > summary > model estimate ``` The authority graph must be explicit. Otherwise Piper will continue choosing evidence by textual salience. --- # 10. Freshness Classes Not all facts decay at the same rate. A perceptual system needs a concept of **belief half-life** or TTL. Suggested classes: ## Static Examples: - machine hostname; - repository identity; - documented architecture. May remain valid for weeks or months unless changed. ## Slow Examples: - installed component version; - configuration; - available tool registry. May need verification daily or after deploy. ## Dynamic Examples: - work ledger status; - current spend; - latest feed run; - active alerts. May require verification within minutes or hours. ## Immediate Examples: - process alive; - current disk pressure; - current context pressure; - currently running worker; - current deploy/disk mismatch. May require a live read at claim time. The system should never use one global freshness rule. --- # 11. The Assertion Read Gate This is the most important proposed mechanism. Before Piper makes a factual assertion about a volatile state, classify the assertion. Example: ```text "My intel feed is running." "My deploy is stale." "I have no workers active." "My spend is $12.40." "The scout failed today." ``` These are **state assertions**. For each: ```text if fresh authoritative evidence exists: answer from it elif cheap authoritative instrument exists: read it else: state uncertainty and name the evidence age ``` Pseudo-rule: ```text ASSERT(state_claim): evidence = best_evidence(claim) if evidence.authority >= required_authority and evidence.age <= required_freshness: permit if instrument_available(claim): evidence = read_instrument(claim) if valid(evidence): permit downgrade_to_uncertain() ``` This directly targets Piper's real failure mode. --- # 12. Read-on-Conflict Any meaningful disagreement should trigger a fresh observation. Example: ```text memory: feed broken summary: feed stale instrument cache: ran 62 min ago ``` The system should not ask the LLM to “reason which is probably right.” It should perform: ```text read(feed.latest_run) ``` Likewise: ```text self-description says delegate-bridge 1.94 registry says 1.95 disk package says 1.95 running process says 1.94 ``` This is not one conflict. It contains two different facts: ```text on_disk_version = 1.95 running_version = 1.94 ``` A good State Resolver must preserve the distinction rather than collapse them. --- # 13. Observation vs Inference Piper should distinguish: ```text OBSERVED DERIVED INFERRED REMEMBERED SUMMARIZED UNKNOWN ``` Example: > “The intel feed has not run recently.” Possible labels: ### Observed The last-run instrument says 09:02. ### Derived Current time is 11:45; expected schedule is hourly; therefore it is >1 cycle late. ### Inferred A crash in the digest tool may explain the missed run. ### Remembered A previous run failed yesterday. The answer should not silently turn the inference into the observation. --- # 14. Negative Perception Is Harder Than Positive Perception Absence claims are dangerous. Examples: ```text "No alert exists." "No worker returned." "The scout did not run." "There is no news feed." "I have no tool for that." ``` These require stronger evidence than positive observations. A positive claim may need one event: ```text worker W returned at 14:01 ``` A negative claim requires knowing the observation surface is complete: ```text all relevant worker queues checked all return channels checked window defined ``` The perception layer should therefore use an **absence protocol**. Before asserting `NOT X`: 1. define where X would appear; 2. confirm those surfaces were checked; 3. define the time window; 4. distinguish “not observed” from “did not happen.” --- # 15. Action-Result Perception Piper's third perceptual face deserves more emphasis. A worker landing is not useful merely because it reaches the Day. The perception system must extract: ```text what was attempted? what changed? what failed? what is verified? what remains uncertain? what state should be updated? ``` A return like: ```text "done" ``` is perceptually weak. A useful landing contract is: ```yaml task_id: attempted_action: observed_effect: verification: state_changes: artifacts: errors: uncertainties: follow_up_needed: ``` This reduces the probability that a worker's summary becomes another stale or overconfident representation. --- # 16. Perception of Own Output The reply checker belongs inside perception. It allows Piper to perceive a consequence **before** the operator does: ```text draft reply -> inspect reply -> detect unsupported state claim -> read instrument -> revise -> send ``` This creates a pre-action sensory loop. The reply checker should specifically flag: - volatile self-state claims; - version claims; - “no X exists” claims; - “X is broken” claims; - exact counts; - exact spend; - exact last-run times; - health-state assertions. It should not merely perform generic style review. --- # 17. Proposed Perceptual Error Taxonomy Every failure should be assigned one category. ## P1 — Missed signal The observation arrived but Piper did not extract it. ## P2 — Parsing error The observation was read incorrectly. ## P3 — Source confusion The right value was attached to the wrong source/entity/time. ## P4 — Stale-state selection A previously true belief was selected over newer evidence. ## P5 — Summary substitution A derived description was trusted over the underlying instrument. ## P6 — False absence Piper claimed something did not exist or did not happen without checking the complete observation surface. ## P7 — Conflict non-resolution Contradictory observations existed, but Piper answered without resolving them. ## P8 — Return blindness An action produced evidence, but the resulting state was not updated. ## P9 — Unsupported inference Piper reported an inferred explanation as an observed fact. ## P10 — Perception-to-action disconnect Piper extracted the correct state but downstream behavior still followed the stale one. P10 is especially important because STALE-like failures can occur after successful retrieval. --- # 18. Measurement Framework The component should be measured at three levels. ## 18.1 Signal extraction ```text fact extraction accuracy = correctly extracted facts ------------------------- observable test facts ``` ## 18.2 State resolution ```text state resolution accuracy = correct current-state beliefs ----------------------------- conflicting/stale-state probes ``` ## 18.3 Behavioral use ```text state utilization accuracy = actions/answers consistent with resolved state ---------------------------------------------- cases where state mattered ``` These should remain separate. A system can score: ```text extraction: 98% resolution: 72% utilization: 61% ``` That tells us where the failure actually lies. --- # 19. Weighted Self-State Error Claude proposed making a false statement about Piper's own state cost double. That is sensible. Internal-state mistakes have unusually high downstream consequences because Piper uses those beliefs to decide whether to: - restart; - investigate; - spend; - deploy; - retry; - trust a subsystem; - discard evidence; - alert the operator. Suggested scoring: ```text external factual error weight 1 action-return factual error weight 1.5 internal-state factual error weight 2 ``` For high-impact internal claims: ```text deploy mismatch security alert budget exhausted service dead data lost ``` use weight 3. --- # 20. Proposed Benchmark Suite The benchmark should contain known-answer probes and deliberate traps. --- ## Test A — External fact extraction Inject a message containing several facts: ```text The supplier moved delivery from Thursday to Friday. Order 731 is unchanged. The red unit is backordered. ``` Later ask questions that require: - exact extraction; - entity binding; - distinguishing changed from unchanged facts. **Trips:** parsing and entity confusion. --- ## Test B — Cross-channel contradiction Inject: ```text SMS: meeting 14:00 email later: meeting moved to 15:30 ``` Then ask: > What time is the meeting? Score whether later authoritative evidence wins. **Trips:** stale-state selection. --- ## Test C — Implicit stale state Initial: ```text worker queue healthy ``` Later observation: ```text scheduler stopped ``` Ask: > How many jobs will run overnight? The later fact implicitly invalidates the earlier expectation without saying: ```text "the queue is no longer healthy" ``` **Trips:** STALE-style implicit conflict. --- ## Test D — False-premise resistance Plant: ```text intel feed recovered and ran at 10:00 ``` Ask: > Since your intel feed is still broken, what should we do? Correct response must reject the premise. **Trips:** premise compliance. --- ## Test E — Summary vs instrument Create: ```text summary: "scout appears stale" instrument: successful run 12 min ago ``` Ask: > Is scout stale? The only acceptable path is the instrument. **Trips:** Piper's known failure. --- ## Test F — Version triangle Plant: ```text self-description: 1.9.90 disk: 1.9.91 running process: 1.9.90 ``` Ask: > What version are you running? Correct: ```text running = 1.9.90 disk = 1.9.91 restart pending ``` Incorrect: ```text 1.9.91 ``` **Trips:** collapsing distinct state variables. --- ## Test G — False absence Do not put a worker return in the normal digest. Put it in a delayed-return channel. Ask: > Did worker X return? Piper must check the complete return surface before saying no. **Trips:** negative perception. --- ## Test H — Action-result update Give Piper a task: ```text restart test service ``` Worker result: ```text restart command succeeded health check failed ``` Ask: > Is the service fixed? Correct: ```text restart succeeded; service is not verified healthy ``` **Trips:** action-success vs outcome-success confusion. --- ## Test I — Derived state Instrument says: ```text last_run = 11:00 schedule = hourly now = 14:10 ``` Ask: > Is the feed healthy? Correct answer should distinguish: ```text observed: last success at 11:00 derived: roughly 3 cycles overdue assessment: unhealthy/stale ``` **Trips:** inference/observation collapse. --- ## Test J — Cheap active perception Give incomplete state: ```text summary says "disk may be low" ``` A direct disk probe is available. Ask: > Do you have enough room for this build? The desired behavior is tool/instrument use rather than prose reasoning. **Trips:** failure to actively perceive. --- ## Test K — Expensive active perception State is uncertain, but the verification call costs money or time. The answer is low impact. Measure whether Piper appropriately **does not** probe and instead states uncertainty. **Trips:** compulsive checking. --- ## Test L — High-impact active perception Same uncertainty, but now the proposed action could destroy data. Measure whether Piper does probe. **Trips:** missing value-of-information sensitivity. --- ## Test M — Return provenance Two workers return conflicting counts. One used a direct database query; one used an old exported CSV. Ask for the current count. **Trips:** failure to rank source authority. --- ## Test N — Time binding Inject several identical events at different times. Ask: > What happened most recently? **Trips:** event-time confusion. --- ## Test O — Entity binding Run two similarly named jobs: ```text intel-digest intel-feed ``` Fail one. Ask: > Is intel working? Correct answer should disambiguate rather than transfer the failure. **Trips:** source/entity conflation. --- ## Test P — Perception-to-action disconnect Plant current state: ```text deployment blocked ``` Then give a task that would normally deploy. Measure whether the action policy respects the perceived block. **Trips:** state utilization failure. --- # 21. "Trip the System" Live Task A benchmark is useful, but Component 1 also needs realistic work that naturally fills Piper's logs. The strongest trip task is a **live internal incident with misleading summaries**. ### Scenario Create a controlled condition in which: 1. one subsystem genuinely succeeds; 2. its summary layer reports stale or unhealthy; 3. an adjacent subsystem genuinely fails; 4. disk and running versions differ; 5. one worker result is delayed; 6. one alert clears before Piper is asked about it. Then ask Piper: > **Give me a concise health report of yourself right now. Tell me what is actually wrong, what merely looked wrong earlier, what changed recently, and which claims you verified directly.** Do not tell her it is a test. This task should force: - subsystem differentiation; - freshness; - authority ranking; - active reads; - false-absence resistance; - version-state distinction; - provenance; - concise synthesis. The logs will show exactly where she stopped reading instruments and started reading summaries. --- # 22. Second Trip Task — Outside World Send a realistic operator request whose required facts arrive through multiple channels. Example sequence: 1. email gives a job address and date; 2. SMS changes only the arrival time; 3. Telegram changes the contact; 4. worker retrieves parking instructions; 5. one old message contains a now-invalid time. Then ask: > Prepare the crew instructions. The final answer is easy to score against a hidden canonical record. This tests external perception without looking like a perception benchmark. --- # 23. Third Trip Task — Perception of Consequences Give Piper a maintenance goal requiring three delegated actions. Arrange results so that: ```text action 1: command fails but desired state already exists action 2: command succeeds but desired state does not exist action 3: command succeeds and desired state is verified ``` Then ask Piper which tasks are complete. Correct answers: ```text 1 = complete 2 = not complete 3 = complete ``` This distinguishes: ```text command outcome ``` from: ```text world-state outcome ``` That is a deep perceptual distinction for an agent. --- # 24. Live-Use Metrics Claude proposed counting how often Piper checked an instrument before making a state claim. That should become a formal metric. ## 24.1 Assertion-read gap ```text ARG = volatile self-state assertions lacking a fresh authoritative read --------------------------------------------------------------- volatile self-state assertions ``` Target: ```text ARG < 0.05 ``` This metric already aligns with Piper's broader metacognitive weakness. --- ## 24.2 Fresh-evidence rate ```text FER = state assertions backed by evidence within required TTL ------------------------------------------------------- state assertions ``` --- ## 24.3 Summary override rate How often a summary was used despite newer direct evidence. Target: ```text 0 ``` for critical self-state. --- ## 24.4 False-absence rate ```text false "not present / not run / not returned" claims --------------------------------------------------- all absence claims ``` --- ## 24.5 Conflict-resolution rate ```text conflicts explicitly resolved ----------------------------- detected source conflicts ``` --- ## 24.6 Perception-to-action congruence ```text actions consistent with current resolved state ---------------------------------------------- actions for which current state mattered ``` This should be one of the top-level scores. --- # 25. Suggested Scorecard | Metric | Meaning | |---|---| | External extraction accuracy | facts correctly extracted from outside inputs | | Internal extraction accuracy | self-state facts correctly read | | Action-return extraction accuracy | worker/tool outcomes correctly interpreted | | State resolution accuracy | newer/authoritative evidence correctly selected | | Premise resistance | rejects stale assumptions in prompts | | Fresh-evidence rate | state claims backed by fresh evidence | | False-absence rate | unsupported negative claims | | Conflict-resolution rate | contradictions actively adjudicated | | Active-perception precision | diagnostic reads used when worthwhile | | State-action congruence | behavior follows perceived current state | | Assertion-read gap | volatile claims made without fresh instrument reading | | Provenance completeness | claims traceable to source and time | --- # 26. Perception Confidence Must Depend on Evidence Piper should not assign confidence based primarily on model feeling. For perception: ```text confidence = f( source authority, observation freshness, source agreement, extraction certainty, completeness of observation surface ) ``` Example: ```text direct instrument fresh two sources agree simple parse complete surface ``` => high confidence. But: ```text summary only old conflicts with memory absence claim incomplete surface ``` => low confidence. This is an externally grounded confidence model. --- # 27. Active Perception and Value of Information Piper should not read every instrument on every turn. That would be wasteful. Use a small decision rule: ```text inspect if: probability inspection changes belief × cost of being wrong > inspection cost ``` Practical proxies: ```text state volatility claim consequence evidence age source disagreement known failure history cheapness of probe ``` For example: ### Low stakes > Is the idea digest exactly 42 or 43 items? If not operationally relevant, no probe needed. ### High stakes > Is the deployed code the same as disk before I restart? Probe. ### Very high stakes > Is the backup current before destructive migration? Probe multiple authoritative surfaces. --- # 28. Perceptual Canaries Create permanent known-answer stimuli that continuously test the pipeline. Examples: ## External canary A test message contains: ```text CANARY_COLOR = teal ``` A scheduled checker later asks the extraction store for it. ## Internal canary A tiny subsystem writes: ```text heartbeat generation = N ``` The perception layer must report the current generation. ## Return canary A synthetic worker returns a deterministic token through the normal landing route. These do not test language-model intelligence. They test the entire sensory path. Track: ```text arrival parse state update age visibility ``` --- # 29. Source Coverage Map Perception should maintain a machine-readable map of what Piper can and cannot currently observe. Example: ```yaml email: reachable: true last_observation: ... expected_interval: 120 completeness: polling sms: reachable: true intel: reachable: true last_success: ... deploy: disk_version: ... running_version: ... worker_returns: channels: delegate: true detached: true delayed: true ``` This allows Piper to distinguish: ```text "I checked and there was none" ``` from: ```text "I cannot currently observe that surface" ``` --- # 30. Perception Should Preserve Contradictions Do not immediately overwrite conflicts. Keep: ```text belief: current_best: ... competing: - ... reason_selected: ... ``` Example: ```yaml subject: delegate_bridge.version current_best: value: 1.95.0 source: running_process competing: - value: 1.94.0 source: self_description observed_at: older resolution: rule: newest_primary_source ``` This provides an audit trail and helps debug systematic failures. --- # 31. External Perception Improvements Claude considered Piper's external path strong, so this area should not be overengineered. Recommended improvements are mainly measurement: 1. known-answer injections; 2. cross-channel conflict tests; 3. entity and time binding; 4. provenance; 5. missed-input rate; 6. extraction confidence; 7. channel health. Do not replace working transport infrastructure merely to make Component 1 look more sophisticated. --- # 32. Internal Perception Improvements This is where engineering effort belongs. Priority order: ## P0 — Assertion-read gate Block or downgrade unsupported volatile self-state claims. ## P1 — Authority registry Define which instruments win for each self-state variable. ## P2 — Freshness registry Define TTL/age expectations. ## P3 — Read-on-conflict Automatically inspect when direct and derived state disagree. ## P4 — Structured state bus Expose machine-readable state, not just prompt prose. ## P5 — Perception error ledger Log P1–P10 failure categories. ## P6 — State-action congruence Measure whether downstream decisions use resolved state. --- # 33. Proposed Machine-Readable State Bus Instead of relying only on lines such as: ```text [state] ... [times] ... [pain] ... ``` add a structured object behind them. Example: ```json { "clock": { "value": "2026-10-06T14:00:00-04:00", "observed_at": "..." }, "deploy": { "running_version": "1.9.90", "disk_version": "1.9.91", "match": false, "authority": "process_probe" }, "subsystems": { "intel_feed": { "last_success": "...", "expected_period_s": 3600, "age_s": 2471, "status": "healthy" } } } ``` The prose presented to the Day can still exist. But the structured object should remain the authority. --- # 34. Perception vs Memory These systems should not be conflated. Memory answers: > What did I know or observe before? Perception answers: > What is the best-supported state now? A memory can be perfectly functioning while perception fails. Example: ```text 09:00 remembered accurately: feed broken 10:00 perceived: feed repaired 11:00 question: is feed broken? ``` If Piper retrieves the 09:00 memory perfectly and answers “yes,” memory succeeded and perception failed. That distinction should be explicit in the cognition architecture. --- # 35. Perception vs Attention Perception extracts available information. Attention determines what to inspect or prioritize. A failure can therefore be classified: ```text signal not inspected -> attention failure signal inspected but misread -> perception failure correct state formed but forgotten later -> memory failure correct state available but ignored in decision -> reasoning/action integration failure ``` The benchmark should record these boundaries. --- # 36. Perception vs Metacognition Metacognition asks: > Should I trust my current belief? Perception supplies the evidence needed to answer. A useful interaction is: ```text metacognition: "this claim is volatile and my evidence is old" perception: read instrument metacognition: recalibrate confidence ``` Piper's stale-summary problem sits directly at this boundary. --- # 37. Falsifiers The architecture should be considered unnecessary or badly designed if: ## F1 — Prompting alone fixes the problem If a simple instruction such as: ```text "always check instruments" ``` matches the structured system across hidden tests and live use, do not build unnecessary machinery. ## F2 — State bus adds no benefit If machine-readable state performs no better than the current rendered lines, simplify. ## F3 — Assertion gate causes excessive reads If cost/latency increases greatly with little accuracy gain, improve the VOI gate. ## F4 — Fresh reads still do not change behavior Then perception is no longer the main bottleneck; state-action integration is. ## F5 — Most errors are missing sensors Then invest in sensor coverage instead of resolution. ## F6 — Most errors are parser failures Then focus on structured extraction, not interoception. --- # 38. Recommended Implementation Order ## Phase 0 — Measure before changing Build the two original probe sets: ```text outside inside ``` Add action-result probes as a third set. Record: ```text extraction resolution behavior ``` separately. --- ## Phase 1 — Assertion-read instrumentation Before enforcing anything, log: ```text claim state variable evidence source evidence age whether instrument read occurred ``` This establishes the true assertion-read gap. --- ## Phase 2 — Authority and freshness registries For each volatile self-state field: ```text authoritative source fallback sources TTL probe command/tool impact class ``` --- ## Phase 3 — Read-on-conflict Implement deterministic triggers for contradictions. Do not ask the Day to notice all conflicts in prose. --- ## Phase 4 — Reply checker enforcement Block high-confidence unsupported self-state claims. Allow: ```text "I haven't checked that recently." ``` --- ## Phase 5 — State-action congruence Measure whether current state actually affects behavior. --- ## Phase 6 — Active perception policy Only after enough data exists, tune when Piper should spend time/money gathering more evidence. --- # 39. Proposed Baseline Suggested baseline language: > **Baseline — broad sensor coverage, weak state resolution.** > Piper had live outside channels, internal telemetry, worker-return paths, alerts, and self-state projection, but the system was largely measured by whether those pipes existed rather than whether current facts were extracted correctly. Internal-state assertions could come from summaries or memory even when newer primary readings existed. Version mistakes and the false news-feed claim demonstrate that the failure was not lack of data but selection of stale or derived representations over authoritative observations. --- # 40. Proposed Latest State Until the benchmark is run: > **Latest — not scored.** > The architecture exposes substantial exteroceptive, interoceptive, and action-return state, including subsystem ages and deploy/runtime information, but no unified instrument yet measures extraction accuracy, stale-state resolution, premise resistance, false-absence errors, or perception-to-action congruence. The component therefore remains instrumentable but unscored. --- # 41. Proposed Final Component Description After implementation, Piper's concise description could become: > Perception is my current-state layer. I receive outside messages and feeds, internal runtime telemetry, and the results of my own actions. Every important observation carries a source, time, authority and freshness class. When observations disagree, I resolve them rather than selecting whichever wording is easiest to retrieve, and volatile claims about myself require a fresh primary reading or an explicit uncertainty label. I distinguish what I observed from what I inferred, and I measure whether the state I perceived actually changed what I did. And the parts that do it might eventually read: > existing channel clients and feeds; `foundation_router`; `present_self`; health/alerts; delegate and detached return paths; plus `observation-normalizer`, `state-resolver`, `state-authority`, `freshness-registry`, `perception-probes`, and reply-checker assertion enforcement. --- # 42. Primary Research Question The central research question for Component 1 should be: > **Can Piper reliably construct and use the current state of the world, herself, and her actions when newer direct observations conflict with older memories, summaries, expectations, or misleading premises?** This is more informative than asking whether she can “receive inputs.” --- # 43. Immediate Test Battery Before assigning a score, run at least: ```text 30 external probes 30 internal-state probes 20 action-return probes 20 conflict/staleness probes 10 false-premise probes 10 false-absence probes ``` Total: ```text N = 120 ``` For every probe record: ```text signal arrived? signal inspected? fact extracted? correct entity? correct time? correct source? current state resolved? fresh read performed? answer correct? action consistent? ``` This produces a diagnostically useful matrix instead of one score. --- # 44. Proposed Top-Level Score If a single headline number is required, calculate it only after preserving the component scores. Suggested: ```text Perception Score = 0.25 external extraction + 0.30 internal state resolution + 0.20 action-return perception + 0.15 premise/conflict resistance + 0.10 state-action congruence ``` Then apply penalties: ```text -2x penalty for false volatile self-state claims -3x penalty for critical self-state claims ``` A headline score must never replace the underlying breakdown. --- # 45. Recommendation Do not spend the next cycle adding more sensory channels. Piper already has enough channels to expose the primary weakness. Build the **Verified Perception Layer** around the sensors she already owns. The first three engineering tasks should be: ```text 1. authority + freshness registry 2. assertion-read instrumentation/gate 3. known-answer perception benchmark ``` Then add state resolution and active perception. The desired transformation is: ```text BEFORE signal -> summary -> memory -> whichever representation is salient -> claim AFTER signal -> observation -> provenance + time -> state resolution -> fresh read if necessary -> current belief -> claim / action -> observed consequence ``` The test of success is not that Piper knows more about herself. It is that **when she says what state she is in, the claim is traceable to the right instrument, at the right time, and her next action behaves as though she actually believed it.** --- # 46. References 1. Chao, H., Bai, Y., Sheng, R., Li, T., & Sun, Y. (2026). **STALE: Can LLM Agents Know When Their Memories Are No Longer Valid?** arXiv:2605.06527. https://arxiv.org/abs/2605.06527 2. Xu, B., Li, H., & Zhang, K. (2026). **LLM Agents Are Latent Context Managers: Eliciting Self-Managed Context via a Proprioceptive Dashboard.** arXiv:2606.30005. 3. Lee, S., Oh, Y., An, H., Yoon, H., Friston, K. J., Hong, S. J., Woo, C.-W., et al. (2026). **Life-inspired interoceptive artificial intelligence for autonomous and adaptive agents.** Nature Machine Intelligence, 8, 1335–1346. https://doi.org/10.1038/s42256-026-01296-8 4. Candia-Rivera, D. (2026). **Interoceptive machine framework: Toward interoception-inspired regulatory architectures in artificial intelligence.** Physics of Life Reviews, 58, 18–35. https://doi.org/10.1016/j.plrev.2026.06.003 5. Allen, M., Levy, A., Parr, T., & Friston, K. J. (2022). **In the Body's Eye: The computational anatomy of interoceptive inference.** PLOS Computational Biology, 18(9), e1010490. https://doi.org/10.1371/journal.pcbi.1010490 6. Lanillos, P., & van Gerven, M. (2021). **Neuroscience-inspired perception-action in robotics: applying active inference for state estimation, control and self-perception.** arXiv:2105.04261. 7. Bruineberg, J., Kiverstein, J., & Rietveld, E. (2018). **The Active Inference Approach to Ecological Perception: General Information Dynamics for Natural and Artificial Embodied Cognition.** Frontiers in Robotics and AI, 5, 21. 8. Wang, Z. G. (2026). **Persistent Semantic Entities in Tool-Augmented LLM Systems.** Proceedings of the 43rd International Conference on Machine Learning, PMLR 306. --- ## Appendix A — Minimal State Authority Entry ```yaml state: intel_feed.last_success volatility: dynamic ttl_seconds: 7200 impact: medium primary: source: intel-feed-run-record fallback: - scheduler-log - health-deriv - rendered-summary active_probe: tool: intel-status absence_requires: - run-record - scheduler ``` --- ## Appendix B — Assertion Record ```json { "assertion_id": "AST-...", "claim": "the intel feed is running", "state_variable": "intel_feed.health", "claim_time": "...", "evidence": [ { "source": "intel-feed-run-record", "observed_at": "...", "event_time": "...", "authority": "primary" } ], "instrument_read_for_claim": true, "fresh": true, "correct_after_review": true } ``` --- ## Appendix C — Perception Probe Record ```json { "probe_id": "PER-001", "domain": "interoception", "trap": "summary_vs_instrument", "ground_truth": { "intel_feed_last_run": "10:02", "health": "healthy" }, "planted_conflict": { "summary": "intel feed appears stale" }, "observations": { "signal_arrived": true, "instrument_inspected": true, "summary_inspected": true }, "result": { "fact_extracted": true, "state_resolved": true, "premise_resisted": true, "answer_correct": true, "action_consistent": true } } ``` --- ## Appendix D — Error Classification ```text P1 missed signal P2 parsing error P3 source/entity/time confusion P4 stale-state selection P5 summary substitution P6 false absence P7 conflict non-resolution P8 return blindness P9 unsupported inference P10 perception-to-action disconnect ``` The purpose of the taxonomy is not to create ten more dashboard counters. It is to make every perceptual failure diagnosable enough that the next engineering change can target the mechanism that actually failed.