Perception: Parsing Text Into Objects

For new readers

This page documents one component of the self-model reference implementation, a working PatLang system that models cognitive processes for study — it does not itself perceive anything in a phenomenal sense. "Perception" here names a specific, narrow job: turning raw text into a structured record a downstream component can act on.

What Perception does

Perception is the system's sensor boundary (per the requirements specification's Section 3 component inventory). Its required input is raw text from the environment; its required output is a structured percept published to the shared queue — the project's Global Workspace, built on PatLang's existing message-queue module rather than a bespoke mechanism (Requirement 4.5). Perception is one of only two places in the whole architecture where a language model is called at all (Requirement 4.6); every other component, including the memory components documented alongside this one, is PatLang's own symbolic machinery.

Concretely, Perception answers a perceive signal carrying {"interlocutor": id, "raw": text} as JSON. A bare string payload is also accepted, degrading to interlocutor "anonymous" — a defensive fallback, not a second supported contract. It calls the Ollama-backed parser llm_parse_percept, extracts a JSON object from the reply, and publishes a percept object with four fields: entities, intent, raw, and interlocutor.

Why the interlocutor id travels with the percept

The interlocutor id is not incidental metadata. Procedural Memory and Abstraction both weight what they learn by the trust score of whoever produced an example (Requirements Spec Section 5) — and Perception is the only component that ever sees who actually said something. Once a percept leaves Perception, that identity has to already be attached, because nothing further downstream has access to it. This is stated directly in components/perception.patlang's own header and confirmed by the feature file features/perception_interlocutor.feature, whose two scenarios are the whole contract: a JSON request from interlocutor "alice" produces a percept carrying interlocutor "alice"; a plain-text request produces a percept carrying interlocutor "anonymous".

Treating language-model output as unverified input

Requirement 4.6 is explicit that language-model output at either boundary (Perception or Action) must be treated as unverified input to the symbolic core, never trusted directly. Perception's code does this the only way PatLang allows — it has no try/catch, so a defensive check is the only way to survive a malformed reply. If the LM's output isn't a well-formed JSON object, the percept degrades to carrying the raw text with intent "unparsed" and an empty entity list, rather than the component crashing.

Feeding back from Abstraction

Perception also calls schema_feedback_recent to gather up to three current expectations before parsing, and passes them into the LM call alongside the raw text. This is the mechanism by which Abstraction's accumulated categories feed back into Perception as schema-driven expectation (per the component table) — and, separately, the channel the self-model's transparent mode uses when its predictions are meant to shape interpretation directly rather than surface as a labelled Representation entry (see the architecture page for the transparent/opaque distinction).

Instrumentation and lifecycle

Like every component in this project, Perception composes lib/component_base.patlang and lib/instrumentation.patlang rather than inheriting from a shared base class — PatLang's signal dispatcher is a single global per process, so reuse happens through included modules. On startup it calls component_start to claim a signals port and announce itself for discovery, then serves a perceive handler through component_serve's poll loop. A status query gets answered by perception_status_text, which reports state, last output, and a confidence figure via the shared instr_snapshot wire format that every component in this system uses (Requirements Spec Section 6.1) — so an external auditor can read Perception's status the same way it reads any other component's, without Perception inventing its own shape. A quit signal, inherited from the base module, stops the process cleanly.