https://itara.dev/docs/explanation/Recent content in Explanation on ItaraHugoenhttps://itara.dev/docs/explanation/vision/Mon, 01 Jan 0001 00:00:00 +0000https://itara.dev/docs/explanation/vision/<p>This document describes where Itara is going, not just where it is. It is a living document.</p> <p>Itara — the open-source specification and its reference implementations — is the cornerstone of this vision, not the whole of it. Everything else on this site describes what exists today, working, open source, and usable. This page describes the future that today&rsquo;s Itara is the first step toward.</p> <hr> <h2 id="the-north-star">The north star<a class="td-heading-self-link" href="#the-north-star" aria-label="Heading self-link"></a></h2> <p>A production system should have a declared, validated, and executable topology — how its components communicate and connect — that is easy to change without touching business code, without migration ceremony, and without downtime. And it should be able to do so safely: with the confidence that the new topology is correct before it is applied, that every connection is validated, and that nothing can be misconfigured silently.</p>https://itara.dev/docs/explanation/architecture/Mon, 01 Jan 0001 00:00:00 +0000https://itara.dev/docs/explanation/architecture/<p>This page describes how Itara actually works today — the module structure, the layering rules, what happens at startup, and what happens on a call. For where this is going, see <a href="https://itara.dev/docs/explanation/vision/">Vision</a>. For the formal, normative behavior every implementation must satisfy, see the <a href="https://itara.dev/docs/reference/wiring-configuration/">wiring configuration</a> and <a href="https://itara.dev/docs/reference/metadata-format/">metadata format</a> references.</p> <hr> <h2 id="the-core-idea-in-one-paragraph">The core idea, in one paragraph<a class="td-heading-self-link" href="#the-core-idea-in-one-paragraph" aria-label="Heading self-link"></a></h2> <p>The Itara agent runs before application code. It reads a wiring config, loads the plugins that config actually requires, generates proxies and listeners for each declared connection, and registers everything in the component registry — before the application handles its first request. By the time your entry point executes, the topology is fully wired. Component code calls other components through plain interface references and never knows whether the call goes in-process or across a network — or which language the other component is written in. The specification itself is language-neutral: a Java component and a Rust component can participate in the same topology, wired by the same config, producing a single distributed trace.</p>