HARUMI.
← Back

2026-07 — 2026-08 / 06

Harumi Platform — closing the operating loop

Personal production systemSole developer and operator

OutcomeBuilt a closed operating loop in which a production change is not complete until the repository, deployed revision, runtime proof, roadmap and durable knowledge all agree.

Overview

The platform already had plans, local-model chat, live health and documentation, but they were adjacent tools rather than a system: rules could drift from code, docs could describe retired workloads, and a green pipeline could not prove that the exact change was serving.

Starting gap

Plans, docs, chat and production health existed, but finishing a task did not force them to agree.

System

Input to System to Evidence to DecisionInputSystemEvidenceDecision

Problem

The failure was not missing information; it was missing closure. The same fact appeared in manifests, docs, memory and UI without one authority or an assertion between copies. Security guidance existed as prose while live credentials still appeared in tracked files. Search quality was discussed without a repeatable set of questions that could fail.

Assumption

Initial hypothesis

Putting the existing Markdown into Obsidian would be enough to create a useful knowledge system.

Defined Observe → Frame → Change → Prove → Retain → Re-observe as an executable state machine. Canonical Markdown and durable memory were rebuilt into a read-only Obsidian projection (retired 2026-09-10) with link identity, provenance, freshness and retrieval questions as gates. A shared CI scanner rejects new credential literals. Deployment proof ties the Git commit to the image, running pod and real route instead of trusting “latest” or “Synced” alone.

What the loop found

Observe → Frame → Change → Prove → Retain → Re-observe
13/13 top-3 retrieval · 0 unresolved · 0 ambiguous

The first retrieval benchmark reached the authority in only 8 of 12 questions; after canonical-node and intent repairs, all 13 acceptance cases hit within the top three. On 2026-08-06 the graph reported 63 notes, 99 native edges and zero identity defects.

Rejected approach

Treating the Obsidian UI as another authoring surface. That would create a third copy of each fact with no gate protecting it.

Decision

Keep canonical Markdown and durable memory as the only sources, rebuild a read-only projection, and make graph identity, freshness, retrieval and credential scanning executable gates.

Result

The acceptance check on 2026-08-06 passed on every gate: the projection resolved every link and alias, and all 13 retrieval cases reached the authority within the top three. What matters more than those figures is that they were not a snapshot — the graph gate fails the build on a single unresolved link or ambiguous alias, and an alert fires on the running projection, so while it ran the property was re-proved on every sync rather than on the day it was measured, and it held as the projection grew by more than a factor of three. The projection was retired on 2026-09-10: Plans, repository docs and memory had become the working surfaces, and a mirror nobody opened was a sync to keep alive for nothing. A deliberately planted credential made CI fail before its removal restored green. The same runbook then rotated Redis and all Kafka identities in production, proving data recovery, quorum health, the MakeUp consumer path and rejection of retired credentials.

Open debt

Debt: Historical credential findings remain baselined in three repositories; the gate prevents growth, but the remaining debt still needs removal.

Next gate: Drive the credential baselines to zero, then add only evidence-backed diagnostic tools that can preserve the same no-secrets boundary.

Project timeline

  1. 2026.07–08

    The console closes its own operating loop

    Canonical rules, executable gates and a read-only knowledge projection turn each production result into the next task’s verified starting point.

Next project

Camunda research — a role that closes itself →