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.

Context

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.

Investigation

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 are rebuilt into a read-only Obsidian projection; link identity, provenance, freshness and retrieval questions are 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.

Evidence

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 fix

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 the property is re-proved on every sync rather than on the day it was measured. The projection has since grown by more than a factor of three and still holds it. 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.

What I would change

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

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

Next project

Reverse-engineering a server's front-panel display