Alloy

Appearance

Source Grounding ​

Alloy's design is grounded in the current public descriptions of Foundry and Epilogue Tracker. This page consolidates the grounding from both the Product Brief and the Integration Architecture and preserves their source-note citations verbatim. Up to Reference.

Foundry reality ​

Foundry is described as an event-driven workflow engine for engineering automation. It replaces imperative shell scripts with composable task blocks connected by events, with throttle controlling how far each event ripples through the system. It runs as a daemon, foundryd, with a CLI controller, foundry, communicating over gRPC. Any emitter can fire an event and trigger the same downstream workflow. [F1]

Foundry currently has two Rust-defined layers: an event library and a block library. The event library provides the vocabulary of immutable facts. The block library contains reusable task blocks that declare what events they sink on, what work they perform, and what events they emit. Foundry's workflows are not declared as first-class objects; they emerge from event sink/emit relationships and block self-filtering based on payload fields. [F2]

Foundry's documented direction is especially relevant to Alloy: events and blocks are expected to remain Rust-defined because they benefit from type safety and compile-time guarantees, while the composition layer is intended to be extracted so that teams can declare block participation and event flow through configuration rather than recompilation. [F3]

Foundry already has gate orchestration, preflight gates, verification gates, bounded retry, project iteration, maintenance, vulnerability remediation, validation, and strategic iteration. The documented formations include the full nightly run, iterate formation, prompt formation, strategic iterate formation, maintain formation, vulnerability remediation formation, scan formation, and validation formation. The standard iterate workflow resolves gates, verifies the project is already in a passing state, validates that intent documentation exists, assesses the codebase, triages the finding, creates a concrete plan, executes the plan, verifies gates, and retries on gate failure. [F4]

Strategic iteration already starts to point toward Alloy. It wraps the iterate formation with an outer AI loop that identifies areas for improvement, enters inner iterations, and asks whether further work is warranted. A user can steer this loop with a strategic_prompt, and Foundry uses that prompt during both assessment and continuation decisions. Foundry's charter emphasizes events over orchestration, composable task blocks, throttle-controlled depth, observability, and correctness through Rust types, and explicitly scopes Foundry to engineering workflow automation rather than a general-purpose workflow engine or CI/CD replacement. [F5]

For how Alloy sits relative to this runtime, see Alloy and Foundry.

Epilogue Tracker reality ​

Epilogue Tracker is positioned around keeping user goals visible from discovery through delivery. It helps teams answer who a task helps, what goal it supports, and how it helps that person get there. [E1]

Epilogue Tracker maintains a living model of users, their goals, and the work that connects them. It maps users, goals, and interactions; updates the model from conversations and meetings using AI; and catches missing goals, work that lacks user support, and broken connections. [E2]

The Epilogue Tracker site makes an important architectural claim for Alloy: the backlog should stay focused on people rather than plumbing, while technology decisions, architecture, coding standards, and constraints live as guidance inside the system where tools can access them. [E3]

For how Alloy complements Epilogue Tracker, see Alloy and Epilogue Tracker.

Source notes (Product Brief) ​

Source notes (Integration Architecture) ​

Source: Product Brief §2 (Source Grounding); Integration Architecture §2 (Source Grounding).

Alloy owns meaning. Foundry owns execution.

Copyright © 2026 Mojility Inc. All rights reserved.