CONDUIR: ARCHITECTURE FOR WORK THAT COMPOUNDS Work architected at Fifth9 Architectural programme — The flow below explains the intended composition. Individual implementations and their end-to-end integration have different evidence and maturity. Conduir is a programme of cooperating capabilities. Context, coordination, action, review and governance have distinct responsibilities. The architecture asks how they can form a continuing journey, so useful work and the reasons behind it do not disappear at the next handover. How can each piece of work make the next one more useful? Keep human purpose connected to coordinated action, retained experience and improvements that can be examined. Keeping context, action and review separate makes the work easier to examine. A model may propose a useful action, but the system still needs to know whether it was allowed, whether it happened and what result followed. Collapsing those into a persuasive answer loses the distinction between intention and effect. BUILDING BLOCKS Purpose and context Translate an intention into a shared understanding of the task. Receives: A goal, constraints and relevant background. Produces: A scoped brief and context that collaborators can examine. Coordination Bring appropriate people, agents and tools into the work. Receives: The brief, available capabilities and responsibilities. Produces: A plan, assignments and handovers. Action and tools Carry out permitted work and report what happened. Receives: An authorised task and its required inputs. Produces: Results, attempted actions and execution records. Memory and review Preserve useful context and examine proposed results. Receives: Work products, decisions and supporting records. Produces: Relevant context, findings and reasons for accepting or revising work. Governed improvement Keep proposed changes separate from the decision to adopt them. Receives: Observed outcomes, proposed improvements and constraints. Produces: An approved change, a revision request or a retained lesson. WALKTHROUGH 1. State the purpose Make the intended outcome, unresolved choices and what must remain under human direction available to later contributors. A task description is useful only if a reviewer can recognise what would count as progress. 2. Assemble the work Choose capabilities and responsibilities according to the work, and preserve enough context for their handovers. A change in tools or participants should not silently change the purpose or permitted scope. 3. Act within the brief Carry out permitted activities and record their results. Keep proposed actions distinct from observed effects. A failure or incomplete attempt needs to be visible to the next contributor rather than converted into an apparently successful result. 4. Examine the result Check what happened, challenge the result and preserve the reasons for the decision. Compare the work with the brief and inspect the supporting records. Retain useful disagreements and remaining conditions, so a later decision does not depend only on a polished summary. 5. Inform the next attempt Use retained context and evaluated lessons to propose a better approach. Decide which context is worth retaining and which change needs a separate experiment. A remembered lesson, an adjusted procedure and a trained capability require different kinds of evaluation. ILLUSTRATIVE EXAMPLE — Improve a small service A team wants to improve a small internal service. The brief defines the improvement. Specialist contributors examine the affected area, propose a change and test it. Review records the outcome and its reasoning. Later work can consult that record instead of reconstructing the same decisions. If a check exposes a problem, the result should return for revision rather than be recorded as a completed improvement. The useful record includes what remains unresolved. A result whose purpose, checks and remaining questions can inform later work. Illustrates the architectural journey; it is not a claim that every stage currently operates as one integrated service. Why these responsibilities are separate Improvement is another explicit boundary. A retained outcome can inform a later proposal, but adopting a change needs evaluation and control over what becomes part of the system. The architecture therefore connects memory to a change process rather than treating every completed task as automatic self-improvement. SCOPE Layered service implementations for routing, model access, memory and review. Protected governance and identity responsibilities, with separate proposal and promotion decisions. REMAINING QUESTIONS Can a complete journey retain its original purpose through handovers? Which retained lessons improve a later task? Can changes remain understandable and reversible? BOUNDARIES AND EVALUATION Purpose and outcome: A coordinated workflow is not automatically a successful outcome. Evaluation: Follow an intended outcome through context, handover and action, including an interrupted or rejected step. Retained context versus learning: Stored records do not by themselves establish useful learning. Evaluation: Retrieve the reasons for a previous decision and examine whether they still apply to the next task. Governed change: An improvement proposal does not establish a dependable autonomous improvement cycle. Evaluation: Compare a proposed change with its predecessor and examine the decision to accept, revise or roll it back. The aim is work that compounds: retained context, reusable capabilities and governed improvements informed by what actually happened. AI Initiative — public architecture guide.