Thesis

The process of creating & maintaining software architecture design records is tedious, expensive, sensitive to entropy, and resulting artifacts are of limited continued use. [7], [9, p. 2], [14, p. 4]

In environments of rapid change and uncertainty, decisions are made with the intention of revision. [1, p. 2], [2, p. 1] Yet, when previous design decisions are inaccessible (skipped, implicit, or lost) [3, p. 1], [5, p. 2], [6, p. 1] revisions become increasingly difficult and expensive. [7], [8, p. 3], [15, p. 20]

Agentic workflows simultaneously worsen the design "decision gap" while benefitting from context of previous decisions. [11, p. 5], [12, p. 10], [13, p. 3]

This paper aims to re-define architecture design records as active artifacts and a primary step in the software development life cycle.

In environments of uncertainty and change, software architecture designs are decided with the intention of revision. [1], [2]

Yet, when knowledge of design decisions is incomplete, revisions become increasingly difficult and expensive to implement. [3], [5], [8], [15], [16], [17], [17]

Documentation of such decisions typically produces passive artifacts which are quickly outdated. [7], [9], [14]

Agentic workflows widen this "decision-implementation gap" while simultaneously benefitting from context of previous design decisions. [11], [12], [16], [18]

This paper aims to promote decisions to active artifacts in the software development life cycle which act as a foundation and primary step for generating a changeset.

The day I die is the day I stop deciding.

Collective indecision may surpass corruption as the greatest enemy.

Yet, environments of uncertainty and rapid change demand quality decision making ability. [1], [2]

Rapid change demands rapid change. Uncertainty demands maintaining context to analyze & revise decisions. [5], [7], [8], [9]

Modern software infrastructure enables rapid, incremental, measureable, revertable updates from an application's codebase. [19] Of course, long-term decision making ability is not to be solved… but, there is much help to be had in the process. Most help is to be had in software, where we can make decisions an active instrument in the continuous integration and deployment of a software application.

Throughout the life cycle of a software application, many architectural decisions are made. [20]

These decisions are often made in rapidly changing and uncertain environments. [1]

Rapidly changing environments demand rapid updates to previous decisions. Modern software infrastructure enables methodical delivery of updates. [2], [19]

Uncertain environments, in addition to demanding quick responses, demand context of previous decisions. When you respond in an uncertain environment, you must, at the very least, know what you decided before. Lastly, uncertain environments demand quality decisions over long periods of time. Long-term decision quality remains requiring of hybrid intelligence. One should not generally rely on machine inference.

In practice, maintaining a close to context of prior architectural knowledge is rarely accomplished or at great expense. [5], [9], [21]

Architectural decisions and knowledge are subject to many forms of degradation. Incomplete Architectural Knowledge (AK) results in challenges which quickly compound. [22]

Maintaining AK is naturally an open-ended task, and additionally varies from organization to organization to individual project. Thus, it is an ill-defined task in terms of what is required, when it is done, and if it is done well.

Maintenance of AK is thus a continuously evolving definition & process — but this does not mean it is intractable. And so, in order to enforce maintenance of AK, a decision must be elevated to a first class artifact; ensuring maintenance of AK through time in response to a stimulus, a decision is the origin point of interaction with a codebase.

[20]

This AK-implementation gap is worsened by agentic workflows naively bolted onto existing software development processes. [11]

Agentic workflows may also be able to bridge the gap. [12]

Relative to code, AK is a secondary artifact. Yet, much literature about Architectural Knowledge Management (AKM) indicates that AK should be considered first-class artifacts. [3], [14], [23], [24], [25], [25]

Promoting AK to a first-class artifact is under-explored. [20]

Throughout the life cycle of a software application, many architectural decisions are made. These decisions often occur in rapidly changing and uncertain environments. [1], [2]

Rapidly changing environments demand rapid updates to previous decisions. Modern software infrastructure enables methodical delivery of updates. [19]

Uncertain environments, in addition to demanding quick responses, demand context of previous decisions. In practice, maintaining a complete context of prior architectural knowledge is rarely accomplished or at great expense. [5], [9], [21]

Architectural knowledge is subject to many forms of degradation. Incomplete AK results in challenges which quickly compound. [20], [22]

This AK-implementation gap is worsened by agentic workflows naively bolted onto existing software development processes. [11]

Agentic workflows may also be able to bridge the gap. [12]

Creation and maintenance of AK is naturally an open-ended task: interpretations may vary between organizations and projects. Thus what is required, if it is quality, and when AK is complete does not have a clear definition. This makes a first-class representation difficult and why, relative to code, AK has remained a secondary artifact. Yet, much literature about AKM indicates that AK should be considered first-class artifacts. [3], [14], [23], [24], [25], [25]

Architectural knowledge lacks the infrastructure and tooling dedicated to code. Promoting AK to a first-class artifact to be operationalized by the core infrastructure and tooling (CI/CD) in a software development lifecycle is under-explored. [20]

Decisions are hard, we make a lot of them, we sometimes revise them (with irreversible consequences), and, crucially, they are of compounding importance over time.

Decisions are shaped by an environment. Yet, environments often develop aspects which negatively impact decision making. Avoiding these detrimental interactions requires new perspectives on the many facets of decisions.

Software engineering has a deep literature to aid us in making quality architecture decisions, documenting architectures effectively, and on.

Quality decision making benefits from such expert knowledge, but requires an intuition of a codebase's circumstances. As intuition weakens, decision making ability follows.

Intution is developed through the friction of work. When the work to generate code becomes frictionless, intuition for the architecture & implementation does not naturally develop.

To facilitate continued quality decisions, intuition for a codebase must be developed and maintained. Without the development of intuition through the authoring of code, friction must be added elsewhere in the software development life cycle.

Decisions are hard, [26], [27] we make a lot of them, we sometimes revise them with irreversible consequences, and they are of compounding importance over time. [28], [28], [29], [30], [31]

Decisions are shaped by the environment in which they are made. [32], [33], [34], [35] When that environment degrades, so does the quality of the decisions it produces. [36], [37]

Software engineering has built a deep literature around this problem: how to make quality architecture decisions, and how to preserve the knowledge behind them. [20] That literature assumes a practitioner with hard-won intuition about their codebase - intuition developed through the friction of directly authoring it. [38], [38], [39], [39], [40]

When code generation becomes frictionless, that intuition does not naturally develop. The environment changes; decision quality follows. [41], [41], [42], [43]

The literature's tools remain valuable. But they were not designed for an environment in which the practitioner's intuition can no longer be assumed. [44], [45] Sustaining decision quality in such an environment requires deliberately reintroducing the friction that frictionless code generation removes. [46], [47]

A software system can be thought of in terms of its form but equally of the underlying decisions. [3], [48] Those decisions shape architecture, tooling, constraints, interfaces, deployment strategies, and future change. Some decisions are revised quickly without much consequence. Others remain embedded for years. Their effects compound over time. [7], [28], [28], [49], [50]

Code is well supported by software infrastructure. It is versioned, tested, reviewed, deployed, and tracked through mature tooling. Decision state is not. The context behind important changes is often scattered across issue threads, diagrams, design notes, chat logs, and individual memory. [3], [51], [51] Put plainly: implementations are reliably preserved in a standardized manner, yet preservation of rationale may vary and only contains fragments. [3], [52]

This "decision-implementation" gap matters because software development depends not only on the ability to generate changes, but on the ability to make and revise decisions under changing conditions. [53] Those conditions are often poor: incomplete information, moving requirements, time constraints, shifting ownership, fatigue, and on. [2], [36], [37], [54] More recently, code generation has changed the relationship between implementation work and architectural intuition. [41], [41], [43] When implementation becomes easier to produce, the understanding once developed naturally through the direct friction of authoring and revising code no longer arises in the same way. [38], [39], [40], [45], [46]

If only a software architect could bend time… to preserve past rationale by broadcasting into the future to those who need it. Best we can do is write our history and try hard to make it discoverable; the ideal of a perfect history is an illusion.

The question is not: did we capture the intent, traces, tickets, diagrams, ….
The question is: how can we interact with each decision in our architecture as it collides with reality? [cite: sw-arch-is-decisions]

History is not a mere linear timeline of events, yet we track our software evolution as a simple sequence. The events of software architecture's evolution form a topology of decisions. It is possible to build a model to represent this. Additionally, we can incorporate into topology the ability to define structural warning signals and other functions.

The progression of codebase's lifecycle surfaces as a sequence of snapshots in time, yet underneath is a rich and complex structure of relationships between decisions past. From the surface one can read and parse a history, while below the surface interdependent decisions are a structure to be queried. Remediation to the codebase bubbles up as additional events occurred, yet each bubble may represent a reconsideration of entire branches of decisions. The surface-level history is calm, still, dead; below lives living, interlinked forests of decisions capable of sensing their collision with reality in the present. [25], [50], [55], [55], [56], [57], [58]

This does not imply replacing git, but building on top (or, to follow the analogy: below). Specifically, an event-sourced Command/Query layer which implements a "decision-gated" protocol in between snapshots. This mechanism links changes in decisions to changes in the code. Additionally, the decision event feed into a topological structure that is configurable, stateful, can be computed on, can define computations, can be inherited, and on. [25], [59]

A simple sequence of changes (actions), $<a_1, .., a_n>$, can mathematically define the states of a codebase's history. The decisions which accompany each change, however, embody a much richer space in terms of structure, relationships, and interactions.

You may imagine the top of an iceberg… you can see the shape exposed above the surface of the water, but that's it.

For a codebase, what's exposed above the surface is the latest state of the code (the sum of all actions). In git, this is referred to as the HEAD. git allows us to go back in time to see how the surface once was. From a back in time, it's easy to see the difference in states (the difference, or, the result of a sequence of actions).

However, when we try to look below (at the decisions), we can't see as clearly. We do our best to keep the docs up to date, write the Architecture Decision Records (ADRs), capture the traces, the specs, create diagrams, etc. This helps, but the clarity when we look below pales in comparison to the of the surface… Down below, there may even be shadows (stale or incorrect information) which we have to ignore in order to see the true shape. You'll most likely have to rely on your hard earned intuition or do some exploration.

Even more difficult: to look underneath and back in time! Wouldn't it be nice to immediately see the entire topology of decisions that once existed? Imagine if you could directly compare against the present decisions… a decision diff! What if we could go even further and know the circumstances of how those decisions came to be and even which lines of code they apply to?

The question I am asking is… in software, can we elevate "decisions" to elements of near equal citizenship as expressions in code? To achieve this, we can mathematically link changes in code to changes in decisions. These first class decisions may have a formal structure, topological relationships, computable warning signals, a stateful protocol, and on.

When humans try to model, navigate, and ultimately affect reality through language, is “decision” a useful general-purpose primitive for organizing that work?

This paper explores whether a decision-first system can function as a general coordination substrate across domains

Such a system may serve not only as a record of decisions, actions, and commitments, but also as a navigable model of a decision space: its adjacent possibilities, trajectories, and contradictions within a domain.

This work sits at the intersection of design rationale, design space analysis, collaborative decision support, and decision provenance, but extends them toward a decision-first execution model in which decisions act as a general coordination substrate across domains.

Machine learning of language has let one generate code at super-human speed while relaxing the necessary precision… the same assistance shadows, pollutes or erodes (union, not xor) the hard-earned & embodied : skills & decison-making intuition (2^2) that cultivate quality codebases, a threat this paper calls "decision mode collapse."

If a software system is most truthfully represented as the set of decisions behind it, then preserving decision quality and intuition across the SDLC requires first-class tooling for decisions themselves, not just the code (a rigorous projection).

Application-level decisions in a SDLC are not "high-stakes" as in health or education domains. (Ignoring costs and assuming expertise) Decisions in software may be: implemented many ways, changed later, evaluated ahead of time, incrementally rolled out, automatically rolled back, etc.

Application-level decisions (not: multi-application system wide architecture & physical infrastructure) in a given project's SDLC involve choices and tradeoffs between common frameworks, architecture patterns, database integrations, etc. Popular application-level practices in popular languages are reasonably represented in Large Language Models (LLMs) [60] and implementation by agentic systems is reasonable with enforceable guardrails. [61], [61] However, decision making ability in such agentic workflows is lacking on many dimensions. [12], [12], [44], [44]

Current approaches for integrating agentic workflows into the SDLC augment existing practices. [13], [13] This paper also wonders about augmenting an existing workflow, namely, the ADR, however, the proposed method in the paper molds the ADR into a "structured decision" of which may be able to be adopted widely if it brings meaningful benefits to the SDLC in terms of maintainability, safety, engineering, ethics, trust, cognitive load, education, collaboration, and lastly, by establishing a comprehensive enumeration of software project starting points to be used by anyone (boilerplate repositories to be forked).

Previous approaches of documenting decisions in a codebase have been faced with tediousness, consistent team onboarding and alignment, enforcement difficulty, staleness, high cognitive load, low continual value, isolation, etc. [14], [14], [17], [17]

This paper attempts to mold the idea of the ADR into a set of structured files that lives alongside code and tests. While fundamentally different, these "structured decisions" share one similar aspect: much like lines of code may be covered by a test, many "structured decisions" may cover many lines of code and/or their tests. Do not be fooled: the "coverage" of a "structured decision" is much weaker (to the point that it should not be called coverage) in that it does not actually "cover" a line of code by actually interacting with, or, executing it, and to the further detriment of the definition of "cover", a "covering decision" must additionally manually maintain a one-way verifiable link from decision to code and/or test (a tedious, error-prone task). The creation and maintenance of these manual one-way relationships at least fits with the function of structured decisions: they are the pre-cursor to code and tests and so the creation of these one way relationships will be ahead of time and revised as each decision is made – to change the code you must first make a decision and it will be part of that decisions "plan" which files are interacted with. The difficult part is including all previously defined implicitly included decisions, but some deterministic and semantic rules can be made to ease this burden.

In the SDLC, these structured decisions are at the opposite end of the pull request, hence "PrePR". Structured decisions also function as: parents to multiple variations of plans and their changesets, definitions for reconsideration of a decision, an immutable history of the code evolution, an entry point for code exploration, and on.

The framing this work adopts, that decisions are the substrate from which a software system is most truthfully understood and that memory of a system is best modeled as a projection over those decisions, is not unique to this thesis. A loose movement has been forming, in parallel and largely independent of the academic literature on architectural knowledge management, around the same intuition. Stating where this work sits within that movement matters: the framing is in the air, but the specific protocol proposed here is not.

The deepest precedent is case-based reasoning NO_ITEM_DATA:kolodner1993cbr.

Kolodner defined a case as a contextualized piece of knowledge that represents an experience and teaches a lesson fundamental to achieving the goal of the reasoner; each case carries a problem situation, the solution that was proposed, how the solution was derived, and the outcome. That structure is decision-shaped memory avant la lettre, and case-based reasoning has been revived recently as a framework for LLM agents NO_ITEM_DATA:watson2025cbr-llm-agents.

The belief revision tradition, beginning with the AGM theory NO_ITEM_DATA:alchourron1985agm,

provides the formal apparatus for what an agent is committed to believe, with operators for expansion, contraction, and revision that correspond directly to how a stance enters, leaves, or supersedes another in a decision graph. What this thesis calls a thread with versioned stances and an accepted child, AGM treats as a belief set under revision; the formal semantics are forty years old.

In parallel, the practitioner space is converging on the same shape under the banner of context graphs and decision traces. Foundation Capital's framing of context graphs as "a living record of decision traces stitched across entities and time so precedent becomes searchable" NO_ITEM_DATA:foundationcapital2025context-graphs

appears to be the agenda-setting essay of this cluster. A wave of vendor and research artifacts followed: XMPRO frames operational memory as the accumulated decision traces that capture not just what actions were taken but what reasoning justified them NO_ITEM_DATA:xmpro2025decision-traces;

Cognee positions decision traces as the substrate from which predictive world models are built NO_ITEM_DATA:cognee2025decision-traces;

Cognition.ai applies the same context-graph framing to coding agents NO_ITEM_DATA:cognition2025agent-trace;

Yadav, in a widely circulated essay, calls decision traces "the architecture of organizational memory" NO_ITEM_DATA:yadav2025decision-traces.

Academic instantiations are arriving on the same timeline: A-MEM proposes agentic memory for LLM agents organized as a typed graph NO_ITEM_DATA:xu2025amem,

GAM offers a hierarchical graph-based agentic memory NO_ITEM_DATA:gam2026;

ByteRover inverts the conventional agent-memory pattern by having the same model that reasons over a task curate its own hierarchical context tree with explicit provenance NO_ITEM_DATA:byterover2026.

A second cluster, motivated less by memory and more by audit and explainability, treats agent runs as event-sourced streams. AxonIQ argues that AI agent explainability requires the ability to reconstruct why an autonomous system made a specific decision and that event sourcing provides the immutable, replayable history needed to do so NO_ITEM_DATA:axoniq2025explainability.

Akka frames event sourcing as the backbone of agentic AI NO_ITEM_DATA:akka2025event-sourcing;

the FINOS AI Risk governance framework formalizes Agent Decision Audit and Explainability as a control to be implemented NO_ITEM_DATA:finos2025air-governance;

NIST AI traceability guidance and the EU AI Act exert regulatory pressure in the same direction. The shape these efforts converge on is: an immutable, ordered log of decisions and state transitions, projections derived from that log for query and audit, and explicit provenance from each projection back to the events that produced it.

This is the same shape adopted by this thesis. The convergence is real, and the framing is therefore not the contribution. What remains genuinely this work's, after surveying the surrounding territory, is a specific protocol with four properties not jointly present in the prior art.

First, per-locus authored stance schemas. Case-based reasoning fixes a case representation per domain; AGM is type-free over propositions; event-sourcing systems define event types up front in code; A-MEM and GAM build on a fixed graph schema. The decision environment proposed here treats the schema for what counts as a stance field as itself a configurable artifact authored at the locus, generated into static operation and projection schemas, and version-tracked. Where structured spec-driven engineering [78] picks Gherkin scenarios and domain models a priori as the spec layer feeding code generation, the same spec lives here as one possible stance shape among many, with config deciding what stance fields apply at this thread, and the same machinery accommodating ADR-style rationale, Gherkin scenarios, OpenAPI fragments, or free-form notes without a meta-level switch.

Second, retrospective reconstruction from existing commit history. The forward-only flavor of the surrounding work, instrument the agent now and start emitting decision traces, presupposes that the system was born under the new regime. The decision-environment-seeding protocol developed here walks an existing repository's commit history and reconstructs a decision graph after the fact, with a permissive include/exclude disposition over scoped implementation changes and an ordered patch envelope tying surviving scopes to durable thread, version, and stance records. This makes the protocol applicable to legacy codebases and idempotent under re-application as new commits arrive, neither of which is true of forward-only context-graph products.

Third, a thread, version, accepted-stance-child graph with explicit supersession. Most context-graph products treat memory as an append-only log of traces with similarity-based retrieval; A-MEM and GAM add typed edges but not version succession. Here, decisions live on threads, threads carry an immutable progression of versions, each version manifests a set of stances of which exactly one may be accepted, and the accepted stance can anchor child threads. A new commit revising a prior decision is not a contradiction in similarity space; it is a new version on the same thread, with the previous version preserved and the supersession relation explicit. This corresponds to AGM's revision semantics applied to a typed graph rather than a flat belief set.

Fourth, a two-pass classify-then-patch protocol in which a binary noise/decision classifier is followed by a per-frame ordered graph patch over the existing environment, with retained added or removed lines required to be either excluded by disposition or shaped by exactly one stance. The protocol enforces forward-time causality (decisions cite the implementation scopes they shaped through shaped_scope_refs), supports multi-decision commits with parent-child links between decisions introduced in the same commit, and validates ordered patches against generated operation schemas before replaying them into final projections. None of the surrounding work articulates this specific contract between commit-level diff scopes and decision-graph operations.

Fifth, symmetric authorship across human and machine participants on a single real-time protocol. This claim has to be made carefully, because the surrounding territory is more populated than it first appears. The 2025-2026 multi-agent landscape has standardized peer-to-peer agent communication: Google's A2A protocol NO_ITEM_DATA:a2a2025 treats each agent as both sender and receiver with its own logic and memory,

the Model Context Protocol NO_ITEM_DATA:anthropic2024mcp standardizes agent-to-tool interaction,

and surveys catalog adjacent layers (ACP, Analytic Network Process (ANP)) NO_ITEM_DATA:ehtesham2025agent-protocols.

The major orchestration frameworks (LangGraph, AutoGen/AG2, CrewAI, OpenAI Agents SDK, Google ADK, Anthropic Agent SDK) all advertise human-in-the-loop and increasingly human-on-the-loop operation NO_ITEM_DATA:langchain2025langgraph;

collaborative-memory work extends LLM-agent memory with multi-user access control NO_ITEM_DATA:wang2025collaborative-memory.

What these frameworks have in common is that humans participate as checkpoints around agent execution: they review drafts, approve handoffs, intervene at preconfigured pause points. The protocol's authoring peers are the agents; humans interact through a primary assistant agent or an external review surface. This thesis takes the narrowing step of placing humans on the same authoring tier as agents within the protocol itself, and adds a third authoring tier alongside them: personas. A human and an LLM agent invited to the same thread emit events through the same real-time channel, sign stances under the same ratification rules, and accept or refuse other participants' stances under the same authority predicates. A persona is a non-human, non-LLM participant kind: a deterministic or semi-deterministic evaluator with a fixed identity, an attached scoring contract over named quality attributes, and the same protocol semantics as any other authoring peer. Pre-canned personas (a "security reviewer" that scores stances on confidentiality, integrity, and availability axes; a "performance reviewer" scoring latency and throughput; a "maintainability reviewer" scoring coupling, cohesion, and change cost) auto-populate the cells of a Pugh matrix or the responses and measurements of an ATAM scenario when those stances are composed at a locus. This collapses the human-coordination cost of running an ATAM evaluation, historically the chief obstacle to its adoption outside regulated settings, from "convene three human reviewers per quality attribute" to "compose the stance, the personas score themselves, the human reviews and overrides where needed." The participant-kind taxonomy is therefore not human versus agent but human, agent, and persona, with the same protocol semantics across all three and asymmetries encoded as policy at the locus (which roles a given participant kind may hold, which stances require which signatures, which acceptance predicates apply) rather than architectural facts of the substrate. Authoring effort is further reduced by pre-canned stance schemas shipped with the framework: an ADR shape, an ATAM-scenario shape, a Pugh-matrix shape, a real-options shape, and a free-form note shape, composable and overridable but not required to be authored from scratch by the user before any decision can be recorded. The closest non-AI precedent for the real-time multi-party deliberation aspect is Loomio NO_ITEM_DATA:loomio2012, an online consensus-decision platform operating since 2012 with discuss/decide-with-reasoning/permanent-record structure and four-choice ratification (agree, disagree, abstain, block);

Loomio demonstrates that real-time collaborative decision protocols with persistent records work in practice, but it is human-only, domain-agnostic, and free-form rather than schema-typed, and decisions are not tied to code. The contribution here is the combination Loomio omits: agent and persona peers on the same protocol, schema-typed stances with pre-canned shapes, and explicit linkage to implementation scopes through the same patch envelope that records human authoring events.

Sixth, a protocol-neutral container for established software engineering decision practices. The decision-trace and context-graph literature is almost entirely AI-flavored, motivated by the audit and explainability of LLM behavior; its decision objects are agent runs. The framing here is broader: an architectural decision in the sense of Tyree and Akerman [1] is a stance, an ATAM scenario in the Kazman/Klein/Clements sense [85] is a stance shape with stimulus, response, and measurement fields, a Pugh matrix [86] is a stance shape, a real-options analysis [30] is a stance shape, an ADR is the degenerate case of a thread with one accepted stance and a free-form rationale field. Decades of software-engineering scholarship on how to make architectural decisions well, from ATAM through CBAM, set-based design, decision-centric documentation viewpoints [25], and Tofan's systematic mappings of the decision-making research landscape [20], are absorbed into the substrate as authorable stance schemas at the locus that calls for them, rather than reimplemented or replaced. Recent work applying LLMs to ATAM evaluation NO_ITEM_DATA:diasneto2025atam-llm

takes the opposite direction: a one-shot retrieval-augmented evaluation over PDF documents, generating a standalone report with no codebase linkage, no persistence, and no real-time collaboration. That work confirms the gap by negative example: applying an LLM to a stack of ATAM PDFs is not the same as making ATAM scenarios first-class, version-tracked artifacts on a thread that links to commits and welcomes ongoing co-authoring. The claim is not that the substrate competes with ATAM, Pugh, or CBAM; it is that it provides a first-class container for them with version semantics, supersession, role-conditional acceptance, and explicit linkage to implementation scopes.

Seventh, memory, orchestration, and audit as projections over the same decision graph rather than separate subsystems. The agent ecosystem in 2026 maintains these as distinct concerns: vector stores or context graphs for memory, orchestration frameworks for routing and handoff, event-sourced logs for audit and explainability, and HITL or HOTL surfaces for human intervention. Each concern has its own data shape, its own storage substrate, and its own integration cost. The proposal here is that all four are projections over a single underlying graph of threads, versions, stances, and shaped scopes: memory is the read projection, orchestration is the write protocol, audit is the patch envelope log, and human-agent collaboration is the multi-author authoring layer of the same protocol. This is the structural counterpart to the philosophical claim that memories are projections of decisions: when the substrate is decision-shaped, the four operational concerns collapse into projections rather than parallel systems with synchronization burden.

Eighth, active stances with reconsideration functions. Every other artifact surveyed in this section, ADRs, context-graph nodes, decision traces, CBR cases, AGM belief sets, ATAM scenarios, Loomio decisions, is a passive record: it is written once and consulted on demand. None of these substrates ships a mechanism by which a recorded decision continues to sense its own collision with reality after the moment of writing. This is the structural reason ADRs go stale: the artifact has no way to fire when the world drifts from its assumptions, so staleness can only be detected by a human who happens to revisit it, and humans don't. The proposal here attaches to each stance an optional reconsideration function: a deterministic or semantic predicate, evaluated on a schedule or against an event stream, that signals when the stance should be revisited. A reconsideration function may be a simple deadman timer (revisit in thirty days), a telemetry threshold (fire when p99 latency on the endpoints this stance shaped exceeds a bound for two consecutive weeks), a code-shape predicate (fire when the file count under a shaped directory crosses a threshold the modularity argument depended on), a feedback-form aggregation (fire when team satisfaction with the stance falls below a quartile), or a semantic predicate evaluated by a model against new commits that touch shaped scopes. A stance with a reconsideration function is no longer a passive record but a long-running, stateful subscriber to the world that emits an event back into the same protocol when its predicate fires, opening a new version of the thread it lives on. This converts the framework from a typed audit log into an active decision substrate, and supplies the engagement loop that every previous "make decisions explicit" tool has lacked: the system reminds the team when a recorded assumption is colliding with reality, which is the same psychological mechanism that makes alerting a sustained ops practice rather than an abandoned one. Reconsideration functions are also the property that most cleanly resists Sutton's bitter-lesson absorption: a sufficiently large model can synthesize a stance's representational shape on demand, but it cannot replace a long-running, stateful, deterministic-or-semantic predicate that subscribes to telemetry and the calendar over months, because that work is computational rather than representational and does not reduce to a batch inference call. The risks are real and named here rather than waved at: cheap default reminders cause alert fatigue, predicates that depend on telemetry pipelines silently fail when those pipelines drift, and as model capability grows the synthesis of reconsideration predicates from prose intent will reduce the human-authoring surface, which is fine for adoption but narrows the framework's distinctive contribution toward the protocol that runs the predicates rather than the schemas they evaluate.

These properties together recover and extend the original sense of cognitive forcing functions. Croskerry introduced cognitive forcing as a unilateral mechanism [88]: a structured interrupt the practitioner imposes on themselves to compel deliberation against bias. The real-time, multi-author decision environment proposed here lifts that mechanism into a multi-party setting and stretches it across time. The forcing function is no longer a self-imposed cognitive routine but an authority-encoded protocol step shared across participants and tools, where ATAM-shaped stances, role-conditional acceptance rules, version-gated supersession, persona-driven scoring, human-agent peer authoring, and reconsideration functions that fire from the future jointly act as deliberation-compelling structure on a team rather than an individual, and across the lifetime of the codebase rather than a single moment of decision. The forcing-function literature in software engineering and clinical reasoning has remained unilateral and present-tense; deliberation tooling such as Loomio has remained free-form, human-only, and passive after the moment of decision; agent-orchestration frameworks have remained AI-only with humans at the perimeter and have no mechanism by which past decisions sense future drift. The claim that survives the literature search is therefore narrower than "memory is decisions" and stronger than any single property in isolation: this is a real-time decision-environment substrate that unifies memory, orchestration, audit, and multi-party deliberation as projections over a single active decision graph, designed so that established software-engineering decision methods can be encoded as pre-canned stance schemas, so that humans, agents, and personas author on the same protocol, and so that recorded stances continue to subscribe to reality through reconsideration functions that fire when the world drifts from their assumptions, providing a medium for designing collaborative forcing functions that span mixed teams and outlast the moment of decision.

The strong philosophical claim that motivates this framing, that memory of a software system is most truthfully a projection over its decisions and that flat key-value memory systems are decision-shaped persistence stripped of the structure that makes decisions auditable, will not survive review as a novel position. That intuition is precisely what Foundation Capital, Cognee, Yadav, and the case-based-reasoning revival are articulating, and it is consistent with what cognitive psychology has been saying about hippocampus-mediated memory for two decades NO_ITEM_DATA:biderman2020hippocampus-decisions.

What this thesis can claim is narrower and stronger: a concrete, executable protocol that operationalizes the framing for software, runs over existing repositories, treats the schema for decisions as itself a first-class authored artifact, and preserves explicit supersession rather than burying it under retrieval similarity.

A residual concern, raised by the same preference-mode-collapse framing this work applies to LLM-mediated decision making [90], applies recursively to the proposal itself. Once the available stance schemas at a locus are fixed, every retained insight at that locus is squeezed into one of those shapes; mode collapse moves from the recall layer to the schema-authoring layer, where it is harder to detect because the structure looks principled. Per-locus authoring partly mitigates this (the schema is closer to the decision than a global type system would allow), version-tracking the config itself preserves the supersession relation at the schema level, and pre-canned schemas sourced from established SE methods (ATAM, Pugh, real-options) reduce the cost without locking the locus into a single shape, but the failure mode is real and the thesis must address it explicitly rather than waving at it.

A related concern is Sutton's bitter lesson: hand-authored structure tends to lose to scaled learned representations over long horizons. Applied here, the concern is real for the representational layer of the framework (schemas, taxonomies, stance shapes); a sufficiently capable future model may synthesize most of these from prose on demand, narrowing the human-authoring surface to a thin remainder. The concern does not, however, apply to the runtime layer. Reconsideration functions and persona scoring contracts are long-running, stateful predicates that subscribe to telemetry, calendars, and event streams over months; this is computational work rather than representational work, and is not what scaled batch transducers do. The framework's most distinctive contribution is therefore most safely located in the active and orchestration layers (reconsideration, persona-driven evaluation, real-time multi-party authoring, projection over a single graph) rather than in the schema layer alone.

Finally, the proposal does not abolish flat memory. Observations, brute facts, procedural skills, and operational details are degenerate decisions in this framing: a single alternative considered, a single outcome, no contention, but still attached to a thread and traceable to the locus that produced them. This is consistent with how AGM treats the addition of a fact (expansion as a trivial revision) and with how case-based reasoning treats trivial cases (still cases). The claim is not that flat memory should be abolished but that it should sit under the decision graph as a degenerate projection of it, rather than beside it as an independent substrate.

Playing off the MDP and incorporating our aforementioned "decisions", we have a semi-MDP, $sMDP = (S,A,D)$.

The decision graph constructed by the protocol described in the Positioning section is not only a record-keeping artifact; it is a retrieval surface designed to be queried by agents during routine SDLC tasks (debugging, refactoring, feature work). This subsection states the empirical claim that motivates the agent-facing side of the framework: an agent that consults the decision index before reading source code completes typical fix-and-refactor tasks with materially fewer tool calls and consumed tokens than an agent operating against raw source alone, while preserving or improving fix correctness.

Three mechanisms produce the saving. First, density of intent. Stance text is authored to explain a region of code, while source is authored to execute it; an authored stance compresses the rationale that an agent would otherwise have to infer by reading several files of implementation. A 2,000-token ATAM scenario describing why a cache layer is structured the way it is replaces several thousand lines of cache code that the agent would otherwise read to reconstruct the same intent, and reconstructs it less reliably than the original author already encoded it.

Second, inversion of the search problem. Standard agent loops treat code retrieval as an open exploratory search: grep, glob, read, refine. The decision graph records shaped_scope_refs from each accepted stance forward to the file, hunk, or line scopes it shaped, which inverts the search into a closed lookup. Given a file path or a failing test, the agent queries "which stances claim to shape this scope" and receives a small, ranked result set, replacing tens of grep-and-read tool calls with a single graph query.

Third, negative knowledge from supersession. Superseded stances on a thread record alternatives that were considered and rejected, with the reasoning attached. This information cannot be recovered from current source because rejected branches are not in the working tree. An agent that consults the decision graph stops proposing fixes that the graph already shows were tried and abandoned, which reduces wasted attempt cycles and the associated context churn.

Risks to the claim are named explicitly. Stances can be wrong or stale, and a confidently wrong stance is worse for an agent than a missing one. Reconsideration functions partially mitigate this by surfacing drift, but the cost of incorrect index entries is real and bounds the benefit. Compression assumes the stance covers the relevant scope; for code that no stance claims to shape, the agent falls back to source retrieval, paying the index lookup as overhead. The benefit is therefore high-precision rather than high-recall: the index is most valuable when its entries can be trusted absolutely, even at the cost of leaving some decisions outside the index.

The decision graph carries shape and inertia. Some regions of the graph are easy to revise (a logging format stance, a non-load-bearing UI choice); other regions are practically immovable (a wire protocol exposed to external customers, a database engine choice that has accreted a year of schema migrations). Today this resistance to change lives in the implicit knowledge of senior engineers who say "we cannot change that" and explain why over coffee. Codebases do not model it. ADRs do not model it. ATAM identifies "sensitivity points" once during a workshop day and never updates them. The decision graph proposed here can model inertia as a computed property of each stance, derived from properties already recorded in the graph.

This framing has clean ancestors in the SE literature. O'Reilly's residuality theory [28] argues that design decisions made long ago constrain future human action and that practitioners should design residues deliberately; the inertia model proposed here is the operational counterpart, measuring residues from graph state after the fact rather than only designing them up front. Bahsoon's real-options framing [30] treats architectural flexibility as the value of preserving options; computing the inertia of a stance is computing the option-cost of its revision, and a graph annotated with inertia is a real-options ledger over the codebase's outstanding commitments.

Inertia also reweights the framework's own active layer. A reconsideration function that fires on a high-inertia stance is a structurally more serious event than one that fires on a low-inertia stance; the same protocol therefore supports natural alert prioritization without manual tuning, addressing the alert-fatigue risk named in the Positioning section. The framework's structural metaphor sharpens accordingly: the codebase has load-bearing decisions and cosmetic decisions, and the graph can tell the team and its tools which is which without anyone having to remember.

The relationship to residuality deserves to be stated in a single sentence, because it is the load-bearing intellectual claim of this method. O'Reilly's residuality theory says good design is what survives stress, and stress must be generated; this work proposes that durably named decision loci, with active stances and reconsideration functions, are a substrate that lets reality itself generate the stress automatically, with survival recorded in graph state as inertia and non-survival recorded as supersession. The architect no longer has to imagine the floods, the resignations, the regulator changes; the operating context supplies them as commits, telemetry firings, and reconsideration triggers, and the graph absorbs them as evidence on specific stances. This converts residuality from a design-time methodology requiring random simulation by an architect into an operating-time property recorded continuously by the substrate. The same epistemology, that we cannot predict what survives and can only build the conditions for survival to be visible, applies; only the source of stress and the granularity of the survival record have changed.

That granularity change is itself the framework's distinguishing position relative to residuality. O'Reilly works at the level of the architecture-as-a-whole: the unit of survival is the system, the stress is applied to the design as a totality, and the residue is a structural property that does not decompose into per-component claims because residuality is about interactions under stress. This work operates at the level of the individual decision: each stance on each locus carries its own scoped commitment, its own reconsideration triggers, its own children, and its own survival history, with inertia computed per stance rather than per architecture. Residuality is therefore a design-time methodology practiced by an architect with authority over the whole system, while the substrate proposed here is operationalizable in the SDLC at exactly the level engineers act on - this caching choice, this auth boundary, this schema migration - and accumulates evidence per decision rather than requiring whole-system simulation. The price of decision-level granularity is a weaker philosophical claim: load-bearing-ness of the whole is treated as recoverable from the inertia of its stances and their relationships, where O'Reilly insists the whole's residuality cannot be assembled from per-part residuality because it is emergent under interaction. This work does not contest that claim at the architectural level; it claims only that decision-level inertia is a useful and operationally tractable signal at a strictly different unit of analysis, complementary to residuality rather than a scale-shifted version of it.

The empirical claim to be tested in this dimension is that, in a held-out reconstruction over a long-lived repository, the inertia signals computed from graph state correlate with revision cost observed in subsequent commits (changes to high-inertia stances are followed by larger blast radii, longer review cycles, more reverts, or more downstream fixes than changes to low-inertia stances), and that an agent informed by inertia signals proposes fewer load-bearing revisions per task than an uninformed agent on the same workload.