HoruSphere Systems

Platform

The build report is the kernel.

Not a control plane, not a graph, not a layer with a name. A single record written by six commands, in a fixed order, that a person can read and a machine can ingest. Every product we have built and every product we have deferred is positioned relative to whether that record is trustworthy yet.

Kernel

Nine linked facts, in order.

Read left to right. Each step is written by a command that ran, and each depends on the ones before it, which is why a package manifest is meaningful and a green badge is not.

1 source context 2 stage timing 3 runner and tool inventory 4 logs and failure anchors 5 cache reports 6 sanitation reports 7 package manifests 8 artifact checksums 9 report outputs
The build report kernel. Steps 1 to 6 are written during execution; 7 to 9 are what a promotion decision or a later product surface actually reads.

Why a report and not a graph

The long-term architecture direction in our documentation is an evidence graph across source, builds, tasks, QA and releases. That remains the direction. It is not the starting point, because a graph derived from unreliable inputs is a more confident version of the same wrong answer.

So the report comes first, and it has to be good on its own terms, useful to a single engineer, on a single machine, with no server involved. Anything that cannot survive that test does not belong in the kernel.

Why the order matters

Step 5 explains step 2. A stage that took twice as long is only interesting once you know whether the cache was cold and why. Step 7 depends on step 6: a manifest listing files that sanitation should have blocked is worse than no manifest, because it launders the mistake into a record.

This is also why we number the commands rather than presenting them as a feature list. The sequence is the product.

Boundary

Who owns what, this year.

A boundary is only useful if it is stated before the argument, not after it. This is the first-year split, and we intend to be held to it.

First-year product boundary.
Component Owns
Horu CLI Local build instrumentation, report generation, profile execution and rule-pack behaviour.
Horu CI Native orchestration, runners, scheduling, history, dashboards, storage and team-level analytics.
Your existing CI Stays a valid launcher indefinitely. Jenkins, GitHub Actions, TeamCity and GitLab call Horu CLI as a step; that is a supported destination, not a waypoint.
Your source control Stays authoritative. Horu reads a narrow slice of source context where a build record needs it, and nothing more.

Later, a platform component would own tenant and project identity, policy, audit, events, integration state and evidence links, and a ReleaseOps surface would own readiness and promotion. Neither exists today, and the boundary above does not depend on either arriving.

Implementation posture

The stack, and the constraints it has to satisfy.

Go-first, open-source-infrastructure-first, and AWS only where cloud is actually required. Each choice below exists to protect a property, not because it was fashionable.

Go One static binary for the CLI and the runner agent. No runtime to install on a build machine that already has enough installed on it.
Postgres The primary database for Horu CI service state. Build records, queues, leases and gate evaluation live here.
S3 S3-compatible object storage for logs, artifacts, manifests, reports and package outputs, so self-hosting stays possible.
no Docker for the CLI
The CLI must not require Docker, a server, an account or a database to deliver first value. This is a hard constraint, not a preference; it is what makes an evaluation take an afternoon instead of a procurement cycle.
native runner agent
The runner installs natively and does not need Docker to register, lease jobs, heartbeat, stream logs, upload artifacts or report status. Build machines with licensed engine installs are not disposable containers.
hosted services in containers
The services we operate ship as container images. That is a deployment decision about our own infrastructure, and it does not leak into what a studio has to install.
deferred infrastructure
Identity servers, workflow engines, search clusters and broad observability stacks are enterprise and platform concerns. None of them is adopted until a near-term feature explicitly needs it.
deterministic before generative
Init checks, cache rules, sanitation, log classification, report generation and gates are rule-based. Any later generated summary is budgeted, auditable, reversible and grounded in linked records, and never required for CLI or CI value.

Adoption

Six steps, in order. Stop wherever the value stops.

This is the path we recommend, in order. Steps 5 and 6 are optional and most teams should not reach them quickly.

  1. 01

    Pick one painful lane.

    One Unity or Unreal build lane where failures are noisy, cache behaviour is unclear, packages need manual cleanup, or the workflow file has become build-engineering glue.

  2. 02

    Add the binary and a config file.

    horu.yaml plus Horu CLI, inside the build you already have. Nothing is removed at this stage.

  3. 03

    Run the commands in place.

    init, run, cache, package and report, called from the existing pipeline. The orchestrator does not change.

  4. 04

    Compare before and after.

    Failure diagnosis time, cache visibility, sanitation findings, package manifests, and how many lines of pipeline glue you deleted. If the comparison is unconvincing, stop here. That is a real outcome, and worth telling us.

  5. 05

    Turn on upload, if history is worth it.

    Optional. horu report --upload sends the same records to Horu CI for list and detail history across the team.

  6. 06

    Move orchestration, only if you want to.

    Optional, and last. Native Horu CI is in development; this step is a conversation rather than a download.

Studio build and test stations set up for release operations across multiple target platforms

Planned scope

Four surfaces waiting on the kernel.

These are documented in our architecture and are not first-year adoption requirements. Each one becomes valuable only after build and package evidence is reliable enough to sit under it.

Planned

  • Horu ReleaseOps Planned

    Release candidates, readiness views, promotion gates, approvals, handoff packs

  • Horu PM Planned

    Tasks, bugs, milestones, asset work, QA triage, milestone readiness

  • Horu Wiki Planned

    Design docs, specs, runbooks, release notes, postmortems

  • Horu VCS Planned

    Connected Git source context, then source-to-package traceability

See what each one would own

Read the kernel, then test it.

If the report is the thing that has to be trustworthy, the only useful evaluation is running it against a build that currently frustrates you.

Request early access Read the Horu CLI reference