Volition and planning now run as part of cognition (PLAN §8.2 item 3):
- A volition hook derives wants after each cycle from what it perceived
and produced, satisfies answer wants when a reply is sent, raises due,
overdue, expired and conflicting commitments, and expires faded wants.
Events produced by earlier cycles are not re-derived.
- An intend process proposes deciding about the strongest undecided
wants; the candidate competes for the workspace, so attention gates
what the mind decides to pursue. The handler makes value tensions
explicit (caution against disruptive writes, privacy against reading
personal data), resolves them with recorded scores, runs deterministic
formation with commitments, policy preview, goals and values, records
the decision whatever it is, and plans a formed intention in the same
transaction. Operator requests carry their own weight in formation.
- Explicit requests in conversation ("restart <unit>", "logs for <unit>",
"fetch <url>") become wants with proposed means instead of direct
invocations; the reply says the request was recorded and that acting
depends on commitments and policy.
- The executor is woken after commits, runs in a scheduler-owned loop and
reacts to the event bus: a new commitment tightens or abandons affected
intentions (withdrawing their pending approvals), a weakened assumption
or a finished goal triggers reconsideration. A tightened plan may reuse
its strategy; a failed one may not.
- Metacognition gains volition checks: strong wants repeatedly set aside,
intentions with no recorded reason, intentions a commitment forbids,
commitments that cannot be kept, churn, repeated failed execution,
cost outweighing value, and intentions that outlived their goal.
- A plan model role and prompt let a model propose decompositions that
the planner validates. Ablations are a fork-only configuration field.
- Approvals required by an intention are described as coming from a
commitment or value constraint. The expectation after an approved
action is linked to the execution event, not the request.
- The wants.values column of the unreleased migration 0026 is renamed
value_keys: VALUES is reserved and the generic snapshot restore does
not quote identifiers.
- The hostile-output security test now uses a message that asks for no
action, because an operator's "status of <unit>" is legitimately a
read-only status check.
Noema
Noema is a persistent, inspectable artificial cognitive runtime.
It is an always-running daemon that hosts one or more minds: cognitive entities with their own identity, personality, memories, beliefs, goals, drives, affective state and history. Minds perceive events, compete internally for attention through a global workspace, retrieve and consolidate memories, form and revise beliefs with explicit evidence, make predictions and learn from prediction error, and act only through a policy-governed capability layer. Everything of consequence is recorded as an immutable cognitive event, so an operator can always ask why.
Language models are used by Noema as cognitive service providers for language understanding, concept extraction, hypothesis generation and narrative. They are not the mind. A mind keeps its identity, memories, beliefs and configuration when the underlying model provider changes.
What Noema is not
Noema does not claim consciousness, sentience, self-awareness or personhood. It simulates mechanisms associated with cognition so that they can be studied and used. Behaviour that resembles emotion, curiosity, preference or identity is a property of the model being run and must not be read as evidence of subjective experience. See docs/interpretation.md.
Noema is also not a chatbot with a memory bolted on. A user message does not go straight to an LLM. It becomes an observation, is perceived, triggers memory retrieval, competes in the workspace, is reasoned about, produces a response intent grounded in stored beliefs and uncertainty, and only then is turned into language.
Architecture overview
┌───────────────────────────── noemad ─────────────────────────────┐
stimuli ───▶ │ perception ─▶ cognitive events (append-only) ─▶ per-mind runtime │
(chat,files, │ │ │
metrics, │ cognitive processes (bounded pool) ◀──┘ │
git, hooks) │ retrieval · association · curiosity · prediction · contradiction│
│ goal monitor · metacognition · reflection · dreaming │
│ │ thought candidates │
│ ▼ │
│ attention scoring (deterministic, inspectable) ─▶ workspace │
│ │ broadcast │
│ ▼ │
│ executive: beliefs · goals · predictions · narrative · response │
│ │ actions │
│ ▼ │
│ capability + policy layer (ALLOW / ASK / DENY) ─▶ tools │
│ │
│ LLM providers · embeddings · PostgreSQL (+pgvector) · metrics │
└───────────────────────────────────────────────────────────────────┘
▲ HTTP API · SSE · web UI · noemactl
Full description: ARCHITECTURE.md. Decisions: docs/adr. Plan and status: PLAN.md.
Screenshots
Captured from a running instance with the sample mind Dani (full set in docs/screenshots).
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Quick start
Requirements: Go 1.26+, Docker with Compose, make.
cp .env.example .env
# set NOEMA_MASTER_KEY (openssl rand -base64 32) and NOEMA_BOOTSTRAP_ADMIN_PASSWORD
make dev
This starts PostgreSQL (with pgvector) in a container, applies migrations, and runs noemad on http://127.0.0.1:8080. Log in with the bootstrap administrator, add an LLM provider under LLM and assign models to the perceive and respond roles, create a mind (or load the sample mind Dani with noemactl mind import configs/minds/dani.json after creating an API token under Account), and open its Conversation tab. Without a model the mind still answers, rendering its state directly.
Configuration
Precedence: built-in defaults → JSON config file (noemad -config path) → environment variables (NOEMA_*) → runtime settings stored in the database and edited in the UI. Secrets come only from environment variables, secret files, or encrypted references; they are never included in exports or rendered back to HTML. See docs/configuration.md.
Development
make tools # staticcheck, gosec, govulncheck
make test-race # unit tests
make test-db # tests that need PostgreSQL
make lint security
See CONTRIBUTING.md and docs/ENVIRONMENT.md.
Security warning
Noema ingests untrusted data (documents, web pages, logs, repositories, model output) and can be granted capabilities that touch real systems. Read SECURITY.md and THREAT_MODEL.md before connecting it to anything you care about. Defaults are restrictive: every action capability starts as ASK or DENY, dreaming can never act, and shutdown is always under operator control.
Cognitive concepts
| Concept | Meaning in Noema |
|---|---|
| Cognitive event | Immutable, typed record of anything that happened inside a mind, with provenance links |
| Epistemic kind | observation, fact, memory, claim, hypothesis, belief, prediction, assumption, inference, opinion. Never collapsed |
| Global workspace | Small, capacity-limited set of currently broadcast thoughts, selected by deterministic attention scoring |
| Working memory | Short-lived, decaying set of active items feeding every cognitive process |
| Memory systems | episodic, semantic, procedural, autobiographical; decay changes accessibility, never deletes |
| Belief | Proposition with confidence, status, evidence for/against, alternatives and version history |
| Prediction | Explicit expectation with window and criteria; resolution produces prediction-error events that recalibrate confidence |
| Drives and affect | Configurable scalar state that biases attention and style; inspectable and resettable |
| Self-model | What the mind can, cannot, and is currently doing; prevents false capability claims |
| Metacognition | Processes that audit the mind's own reasoning and emit warnings |
| Replay | Re-running a recorded cognitive sequence, labelled exact or approximate |
CLI examples
noemactl status
noemactl mind list
noemactl mind create dani
noemactl ask dani "why was atlas slow yesterday?"
noemactl belief list --mind dani
noemactl event inspect <id>
noemactl replay <event-id>
noemactl provider test openai-main
noemactl approvals list
noemactl snapshot create dani
noemactl fork dani --snapshot <id> --name dani-test
Status
Version 0.2.0: all sixteen phases of PLAN.md are implemented, and the epistemic honesty review (PLAN.md §7, summarised in docs/epistemics.md) separated assertions from beliefs, recorded evidence provenance, labelled every score as uncalibrated, added explicit unknowns, temporal beliefs, per-subject source reliability, runtime identity for replay, cognitive forks per model, a causal timeline, audited redaction and Amazon Bedrock. Highlights beyond the first milestone: goals and motivation, predictions and calibration, metacognition, reflection and consolidation, the relationship graph, the capability and policy layer, integrations (research folder, git, Prometheus, webhooks), dreaming, snapshots and forks, cognitive replay, experiments, export/import, TOTP. See CHANGELOG.md, docs/RELEASE_NOTES.md and the API document at docs/openapi.json (also served at /api/v1/openapi.json).
Licence
TBD by the project owner.





