HARUMI

Architecture

How the platform works

How applications run, how changes reach them, and how the system preserves knowledge while limiting access.

Dated infrastructure observations

Not available

01 / PLATFORM

From public request to running application

Kubernetes clusters, an explicit public path, Kafka messaging, an outside observer on its own small instance and a GitOps delivery path; the map names relationships, not addresses or access details.

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

    Build, scan, attest

    GitLab CI compiles the app, 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.

Generated knowledge never becomes another editing surface: disagreement is fixed at the authority it came from.

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 / RUNTIME TOPOLOGY

Dependencies, not inventory

This public map names role classes and correlated domains without publishing operational coordinates.

PUBLIC BOUNDARY

Public edge

Request entry

ROUTING BOUNDARY

Gateway

Explicit route

KUBERNETES PLATFORM

CORRELATED RUNTIME CORE

  • Control authority
  • Fabric + routing
  • Shared state

SEPARATE ROLE

Compute role

Workload capacity

RECOVERY CONTRACT

  1. Source
  2. Restore proof
  3. Runtime readback

A boundary is independent only after recovery is proved.

Relationship map only. It deliberately omits addresses, service inventory and access details. More replicas do not remove a shared dependency.

05 / OPERATIONAL FEEDBACK

Signals return as governed work

Detection, operator action, scheduler truth and resource evidence stay connected without collapsing their separate authorities.

Operational feedback and verification details

ARCHITECTURE WORKBENCH

A private modeling workspace turns reviewed system relationships into versionable ArchiMate artifacts. Browser access stays inside the managed network boundary; public pages receive only redacted, reviewed projections.

MESSAGE CENTER

Typed internal events become durable operator records. Browser push is a privacy-safe projection, never the ledger.

ALERTMANAGER ROUTING

Prometheus detects; Alertmanager groups, inhibits and retries through receiver recovery; occurrence truth remains separate from human acknowledgement.

SCHEDULE REGISTRY

Native schedulers remain authoritative while the read-only registry turns failed, missed, stale and over-duration transitions—and their recovery—into durable operator records.

PRODUCT FEEDBACK PATH

A product user writes feedback; the application stores it and returns a receipt, then relays it to an internal event topic. The browser never reaches the broker, the receipt means durable acceptance rather than delivery, and the operator record is restricted so no notification can carry the text.

RESOURCE OBSERVATIONS

The operator workspace keeps fixed 1h/24h/7d trends, exact comparison tables, freshness and missing-data states. Kafka adds broker health targets and an allowlisted lag path; metrics remain cluster-only.

A failure becomes a new Plan input only after the durable record and source state agree.

06 / 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.