HARUMI

Architecture

One system. Three loops.

Delivery changes the runtime. Knowledge preserves the decision. Security constrains both. Each loop returns evidence to the next requirements review.

01 / DELIVERY LOOP

Requirement to running proof

The arrows are gates, not hand-offs. Failed proof returns the task to observation.

  1. 01 / REQUIREMENTS

    Review the requested outcome

    Confirm the real state, authority, exposure class, material risk and a test that can fail.

    current-state evidence

  2. 02 / PLAN

    Define finish before change

    Every non-trivial task receives a saved, read-back plan with scope, ordered checks and stop conditions.

    Plan ID + checklist

  3. 03 / SOURCE

    Change one authority

    The smallest coherent code, configuration or content change ships with its executable guard and negative case.

    diff + local gate

  4. 04 / PIPELINE

    Test, build, scan, attest

    GitLab CI compiles and tests, builds an immutable image, scans it, and retains supply-chain evidence before promotion.

    pipeline + image digest

  5. 05 / GITOPS

    Declare the release

    A separate tag-bump commit updates desired state. Argo CD reconciles that declaration; no hand-edited runtime becomes authority.

    GitOps revision

  6. 06 / RUNTIME

    Prove the exact deployment

    The Argo revision, workload image, rollout health and real user route must identify the same release.

    SHA + route readback

Runtime readback becomes the next observation.

02 / KNOWLEDGE LOOP

Retain without duplicating authority

AI assists the loop, but evidence and maintained sources decide what becomes durable.

07 / RETAIN

Classify the result

Operational fact, reusable behavior, public evidence—or intentionally no publication.

CANONICAL DOCS

Verified operating facts, standards and SOP.

AI MEMORY

Small reusable behavior and authority pointers—not a second source of truth.

PUBLIC PROJECTION

Only bilingual, reviewed, durable and safely redacted evidence reaches this site.

OBSIDIAN GRAPH

A read-only generated mirror with source SHAs, freshness and graph-health checks.

Obsidian is a generated read-only graph. It does not repair disagreement by becoming another editing surface.

03 / SECURITY ENVELOPE

Layered boundaries, explicit owners

The public diagram names control classes and trust boundaries, never sensitive topology or recovery shortcuts.

  1. 01

    CLOUDFLARE-MANAGED EDGE

    Proxied DNS · TLS · DDoS protection · WAF · Access for private surfaces

    The public edge is measured and drift-reviewed; provider-managed never means unowned.

  2. 02

    HARUMI ROUTING BOUNDARY

    Explicit public routes · internal service paths · cross-boundary grants

    Internal traffic stays internal. A public hostname is never an in-cluster service path.

  3. 03

    KUBERNETES WORKLOAD BOUNDARY

    Namespaces · service accounts · RBAC · security contexts · policy audit

    Least privilege is scoped before enforcement. Broad denial requires evidence, a negative test and rollback.

  4. 04

    DATA AND SECRET BOUNDARY

    Secret references · encryption paths · isolated state · backup and restore evidence

    Credentials and private records never enter public content, images, logs or generated knowledge.

04 / ASSURANCE CONTRACT

What “complete” must prove

Authority
One maintained owner for every fact
Identity
Human and workload access are separated
Supply chain
Source, build, scan and release revisions remain traceable
Change safety
Observe → audit → scoped enforcement → broad enforcement
Recovery
Stateful change requires a recovery definition and readback
Closure
Repository, runtime, Plan and durable record must agree

The architecture is closed only when the observed runtime, delivery evidence, maintained documentation and next starting state agree.