Aether Build Solution

Continuous Assertion with GitHub GitHub に、継続的検収を。

Overview: The Pain Lives at the Seams

The pain of software development is not decided by tool performance or by the skill of individual steps. It is decided at the seams — where a change crosses repositories, teams, and companies. Every part is green, yet the whole is slow. Each change is correct on its own, yet the combination breaks. Ordering and combination checks belong to no one and are covered by the attention of whoever can. Aether Build Solution addresses that structure.

Figure 1: The original pain — every part is green, yet the whole breaks and slows down

Aether Build Solution is the solution layer above the Build product (on a Zuul foundation). Rather than selling a product alone, it designs Build Orchestration into a customer’s development process and hands over the operating pattern with it. It is the embodiment of RE-X’s DevX solution.

Positioning

Aether Build Solution is a buyer-side acceptance solution and a system-test efficiency solution.

Its difference from existing CI is Continuous Assertion. Where CI integrates and verifies each change against the current mainline, Continuous Assertion keeps re-issuing an assertion — “this can be accepted” — about the future state created by a bundle of dependent changes, revoking and re-verifying it whenever its premises change. Acceptance stops being a one-time event on delivery day and becomes a continuous act performed on every change.

Where CI stacks changes up bottom-up and expects the whole to hold, Continuous Assertion asserts top-down, from the whole picture — the future state the set creates — that “this can be accepted.”

Figure 2: CI vs. Assertion — what is tested, and how the verdict ages

Figure 5: The difference in direction — CI is bottom-up, Assertion is top-down

On scope: “gating”, as Zuul advertises it, is too narrow — a gate is a single pass/stop point. What we handle is the whole interval from a change being created to landing: bundling, ordering, testing on a future state, issuing and revoking Permits, landing in order, and leaving evidence. Gating is only one scene in that interval.

What It Means for Management

The benefit reads two ways — the executive’s viewpoint and the project’s viewpoint — and for each, the problem is drawn paired with how the foundation, Zuul, works against it.

The positioning first: Zuul works on Day 2 — the long cycle of operations. Gating and speculative testing keep running, across the whole operating period, against every daily change after introduction.

But because acceptance running on Day 2 is the premise, what gets built on Day 1, and how, changes. Declarations (Topic and Depends-On), dependency design, and cross-cutting scenarios are not retrofitted later; they are built in from the start.

And presales changes too. Because acceptance is continuous and can be shown as evidence, what is sold and how proposals are shaped change. The unit of an order is not “work” but “a verified future state.”

From the executive’s viewpoint

Problem — lead time is lost opportunity: Most of the time until a change arrives is waiting time. Waiting is market arrival delayed — lost opportunity itself. How Zuul works against it: With the change queue and speculative testing, verification proceeds on the future state with all preceding changes applied, without waiting for them to land. The structure of the waiting itself changes, and the lost opportunity shrinks.
Problem — combination failures are business risk: A combination failure costs the most when found at the latest possible point — rework cost, plus schedule and trust. How Zuul works against it: Combinations are tested in the future state before landing, and a failed change is removed from the queue and the rest re-formed. Discovery moves before landing, and the shape of the business risk changes.
Problem — acceptance risk concentrated on delivery day: Concentrating the acceptance decision on the final day means betting on that day. How Zuul works against it: The gate judges every change, so the evidence for “is this acceptable right now” accumulates daily. With set-keeping and Permit layered on top, acceptance stops being an event on delivery day and becomes an assertion made with every change.
Problem — apportionment across vendors becomes negotiation: When apportioning blame becomes negotiation, it costs money every time. How Zuul works against it: Job results and buildset records remain per set, so apportionment is a confirmation of evidence, not an argument. What is being bought also changes: from “work” to “a verified future state.”
Problem — no visibility into where investment speeds things up: If the throttle in the flow is invisible, investment decisions are guesswork. How Zuul works against it: Numbers — queue stagnation, chains of re-verification, assertion revocation rates — remain as records, showing where the flow is throttled. Because the unit of acceptance and the unit of release are the same, release decisions are made by state, not by meeting.

From the project’s viewpoint

Problem — waiting on integration: Waiting for preceding changes to land, competing for merge order — that waiting presses directly on the schedule. How Zuul works against it: Speculative testing lets verification proceed without waiting for landings. The queue carries the ordering, so people do not spend time coordinating sequence.
Problem — rework surfaces late: Green alone, red combined — that failure is heaviest as rework after landing. How Zuul works against it: It fails first in the future state. The failed change leaves the queue and the set re-forms, and the buildset record shows which change it came from. Rework stays a send-back before landing.
Problem — the acceptance load concentrates at the end: Preparing acceptance material all at once on delivery day makes acceptance a final peak. How Zuul works against it: Gate judgments and evidence (job results, logs) remain automatically with every change. Acceptance becomes an accumulation of daily confirmations.
Problem — coordination cost across vendors: If people carry the coordination of order and dependencies, meetings and waiting grow. How Zuul works against it: Dependencies (Depends-On) and order are written in declarations and processed by the queue. When something breaks, you start from the evidence, not from a meeting to apportion blame.

The Concepts

Figure 3: From a change's creation to its landing — the lifecycle of a set

Changes are tested as a set, not one by one.

A Bundle is a set of changes tied together by dependencies, plus their landing order. Related changes are bundled by declaration (on GitHub, a topic label and Depends-On), closed in both directions — the depending side and the depended-upon side — to fix the set being handled. The unit of verification and landing is this set, not the individual change.

Speculative testing on a future state means constructing, in advance, the state that would result if that set were landed in order — the future state — and testing it before it happens. Each change can be correct on its own, yet the combination can still break. Testing the future state lets you learn about that failure before landing it.

The landing decision is also made per set. A one-time permission (Permit) is issued for a future state that passed verification, and changes land in that order (Landing). If the set’s composition, versions, or order change in any way, the Permit is revoked and verification starts over. This is how we guarantee, by mechanism, that “the state that was verified” and “the state that lands” are the same.

The foundation is Zuul: the machinery for testing future states in parallel through speculative execution is Zuul’s. On top of it, our design layers Gateway, which retains the declarations and closes the set, and the translation into the language of buyers and acceptance — Continuous Assertion. (Gateway’s retention of sets is at the stage of advancing implementation and verification.)

The aim is to make E2E testing easier to run. The weight of E2E testing lies less in the tests themselves than in preparing the combined system to actually stand up as a whole. By fusing provisioning technology — standing up the future state’s environment as a real thing — with orchestration technology — bundling changes, ordering them, and flowing them through — E2E testing stops being a special event and becomes everyday verification.

How E2E is positioned (design): E2E is not positioned as testing of individual applications, but as a standing check over the dependencies between repositories — the declared dependency graph. Having dependencies always explicitly declared, and being able to check whether anything is broken, is itself the strength. When a change enters something that is depended upon, the set is rebuilt to include its users and re-tested as a combined future state. The aim is to detect, before landing, the accident of a change embedding a bug into something that was working — an embedded-bug regression. The breaks it checks include moving references such as dev branches and floating tags, mismatches between declaration and reality, disappearance or state changes of dependency targets, and cycles. The execution foundation of this standing check is the fusion of provisioning technology and orchestration technology.

Figure 4: The E2E solution — standing checks over the dependency graph stop embedded bugs before landing

What It Does

Pain inventory — Map where waiting and seams sit across the whole flow, from request to operations.
Method and platform design — Changes as Bundles, verification as speculative testing on future states, and landing split into Permit and Landing, implemented with Build (Zuul foundation) and Gateway.
The GitHub shape — Declarations live on GitHub, the ledger is a hero repository, the face is a combined “bundled PR”, and merging is a required check tied to Permits.
Ordering across companies — The unit of ordering becomes a “verified future state”; bundling, separation, and acceptance evidence across multiple companies are handled in the form of a buyer-side development lead agent.
Operations and improvement — Failure classification (plumbing / job definitions / content / execution environment) and a record of bottlenecks, fed back into improvement.

Slogans (original Japanese, kept verbatim)

Our slogans are never replaced away. Everything we have used stays, on this page, with the wording unchanged; only the placement differs.

看板: Continuous Assertion with GitHub
添え: 「GitHub に、継続的検収を。」
一言（現行）: 「コンティニュアス検収（Continuous Assertion）― 検収は、納品の日ではなく、変更のたびに。システムテストは、組み合わせのまま速く。」
一言（先行）: 「発注者の検収を、勘ではなく証跡で。システムテストは、組み合わせのまま速く。」
一言（初期）: 「変更を、集合で扱う。未来を、先に試す。」
位置付け: 「発注者側の検収ソリューションであり、システムテスト効率化ソリューションである」
位置付け: 「発注者向けの開発リードエージェント」
表明の見出し: 「開発の痛みは、継ぎ目にある」

Where We Stand

RE-X is the vendor that makes cross-project gating on GitHub easy to use — and supports it. No Japanese company is publicly known to offer commercial support for Zuul CI; RE-X stands as the only Zuul CI support vendor in Japan.

Status

Trials and verification are in progress (phase-1 trial, one full gate cycle, and verification of ordering and multi-company separation have begun). We are advancing implementation and verification, and each item’s progress is updated as verification results return.

Pricing is undecided.