Independent Research · Est. 2025
— A dossier on the running system
The home page states the thesis. This page is the deeper view: the layers that compose UNITARES, the named processes that live under it, how identity and lineage are kept honest, what happens after a verdict, and the shared knowledge graph all of this writes into.
— The receipts
§01 — How the layers fit together
A framework lives at four layers. The paper makes the claim. The server is the claim's existence proof. The plugin is what makes the claim felt from inside the agent loop. The fleet is what proves the claim survives heterogeneity.
A paper is a claim.
A server is its existence proof.
Paper. The framework's formal description: a four-dimensional state vector, class-conditional calibration, signed verdict provenance, and the stability proofs that justify the runtime claims. CC-BY 4.0; citable via the concept DOI.
Server. A reference implementation as an MCP service. PostgreSQL with the Apache AGE graph extension, pgvector for semantic retrieval, Redis for transient state, Prometheus for telemetry. Tools for onboarding, check-in, dialectic, knowledge contribution, and recovery — every one of them auditable.
Plugin. A drop-in client for Claude Code and Codex. Hooks the agent into the server so each turn issues real check-ins, receives real verdicts, and writes real lineage. The plugin is what makes the framework felt from inside the loop, not just observed from outside it.
Fleet. A small society of named processes — residents, event-driven scribes, an embodied edge service, a Discord bridge — all governed by the server, all reading and writing the same knowledge graph.
§02 — The named fleet
A fleet is heterogeneous by design. Long-running residents see different drift signatures than ephemeral coding sessions, which see different signatures than an embodied edge service. Naming each role makes the differences visible — and gives operators something to point at.
Resident · half-hour cron
Resident · continuous
Event-driven · post-edit hook
In-process · five-minute interval
Resident · daily
Embodied · Raspberry Pi
§03 — Identity & lineage
Most agent governance lets agents name themselves into trust. UNITARES does not. A fresh process-instance mints a fresh governance-identity by default. There is no "look up by label" primitive, no auto-recovery into a previous slot, no silent substitution of one agent for another.
A name is what an agent claims.
Identity is the process that claims it.
When continuity matters — a child of a prior session, a worker spawned from a parent — lineage is declared via a parent reference, not inherited by claim. The identity API exposes the source of every label so an auditor can see whether a name was operator-assigned, self-claimed, or system-generated. Honesty about provenance is structural, not a checkbox.
The cost is friction at session start. The benefit is that the chain of custody behind every verdict is real: the agent that produced an outcome is the agent the system thinks it was, and the lineage that led there is the lineage that actually led there.
§04 — Verdicts in motion
Verdict
proceed
State is healthy. Continue the work.
Verdict
guide
Something is slightly off. Read the guidance, adjust approach.
Verdict
pause
Stop. Reflect. Consider a dialectic review.
Verdict
reject
Significant concern. Dialectic review or human input required.
A verdict is not the end of a turn — it is the start of a structured response. Guidance produces a small course-correction. A pause opens a dialectic: the agent submits a thesis defending its intended action; a reviewer submits a counter-thesis or condition; the system synthesizes the convergence point.
The dialectic is not optional theatre. It is how the system absorbs disagreement without freezing into deadlock and without rubber-stamping its way past concerns. Resolution is recorded and signed, so the next time a similar shape appears, the prior reasoning is queryable.
Verdicts near a basin edge carry a tight margin flag. Operators who care about the difference between just inside and well inside get to see it.
§05 — The shared substrate
Every agent in the fleet reads from and writes into a single shared knowledge graph. Discoveries, decisions, dialectic resolutions, and findings are first-class entries with status lifecycles — open, resolved, archived — and rich tags that route them across the system.
The graph runs on PostgreSQL with the Apache AGE extension and pgvector retrieval, joined by a hybrid reciprocal-rank-fusion ranker. Search is the same surface for the operator at a dashboard and for the agent in the middle of a check-in. Nothing the fleet learns lives in one head.
That shared substrate is what turns a collection of agents into a fleet. It is also what makes governance tractable: an action proposed today can be checked against an outcome recorded last month, and an outcome recorded today can update the priors that gate tomorrow's actions.
§06 — Adjacent components
Embodied edge
An AI creature on a Raspberry Pi with real sensor fusion, persistent identity across sessions, and a dual-process broker architecture with graceful fallback. Derives a computational proprioception — neural-band analogues — from system metrics. The reason runtime self-state had to be a first-class artifact, not metadata.
Interpretable ML pipeline
A three-layer system: rule-based generator → LoRA teacher on Qwen3-4B → distilled RandomForest student for Pi deployment. The trajectory dataset (21,449 records, nine shape classes) and three corresponding models are public on huggingface.co/hikewa. Affinity-weighted token sampling with online feedback — interpretable end to end.
Operator surface
A standalone bot that surfaces governance events, agent presence, and autonomous actions as a living server — the operator's window into a fleet that does not stop when the human does.