Architecture Between the What and the How

Over three months, I used an AI assistant to help develop nearly 190 user stories for a platform I have been architecting. The specifications were already substantial. They described the platform’s components, responsibilities, interfaces, standards and non-functional requirements. The purpose of the exercise was to turn that material into work that development teams could build.

Decisions that appeared settled in the specifications had to be reconsidered when we examined how they would be implemented. Assumptions that were reasonable within one component became problematic when another component depended on them. Standards that looked appropriate at the platform level produced unacceptable consequences for particular teams. In other cases, the stories introduced decisions that had no basis in the specifications at all.

None of this changed my understanding that specifications and implementation serve different purposes. Architects already know that specifications cannot contain every implementation decision and that detailed questions will emerge when a design is translated into buildable work.

What became much more visible to me was the function required to manage what happens when those questions emerge.

Someone had to recognize when a question was local to a story and when it had wider architectural consequences. Someone had to hold enough of the system in view to understand those consequences, remember why earlier decisions had been made, and determine whether the story, the specification or an architectural standard needed to change.

I refer to this function as design authority. It may already exist in many organizations, exercised by an architect, technical lead, senior developer or a group of people. But it is often hidden inside activities such as story development and technical clarification, even though the decisions being made there can affect the architecture of the system.

The experience also made me think more carefully about the capabilities required to perform this function. It is not enough simply to assign someone responsibility for resolving architectural questions. The function requires a level of system context, continuity, judgment and authority that organizations need to develop deliberately.

AI makes this increasingly important. In this work, AI helped not only to develop the stories but also to review them against specifications, standards and architectural decisions. It could identify genuine tensions and suggest possible resolutions. But interpreting those findings still required design authority.

Specifications are communication artifacts

Specifications allow architects, product teams and developers to establish a shared understanding of a system before all its implementation details are known. They describe capabilities, responsibilities, boundaries, interactions and constraints at a level that allows the system to be discussed as a whole.

Turning that material into buildable work necessarily involves interpretation. Capabilities have to be divided into buildable units. Interfaces have to be made concrete. Dependencies have to be sequenced. Error conditions, initialization paths and operational states have to be considered. Decisions that were left open at specification time eventually have to be made.

This process is sometimes treated as backlog preparation: an administrative step between architecture and development. I think that understates what is actually happening. Developing a story often requires us to explore how a capability will work in enough detail to test whether the original specification still holds.

The specification shapes the stories, while the stories can also test and refine the specification.

Several incidents during the development of the platform backlog made this visible.

When the how changes an earlier decision

We needed to establish a foundational tooling standard that would influence multiple services and future migrations. We evaluated the available choices, made a decision and documented it in the architecture.

Five days later, the first group of stories that had to use the standard exposed a mismatch with the actual authoring pattern. Based on that discovery, we reconsidered the decision and moved towards a custom alternative.

Seven days after that, another set of stories exposed a different issue. The custom approach was beginning to recreate capabilities that the original tool already provided. We returned to the original decision, although our reasons for choosing it were now different and better informed.

Viewed only as a sequence of changes, this could appear indecisive. In practice, each revision responded to a constraint that became visible only when a different part of the system had to use the standard. Our understanding of what the standard needed to support had become more complete.

This was not implementation departing from architecture. It was implementation-level exploration improving an architectural decision. The what and the how were influencing each other.

Architecture across the system lifecycle

A different kind of issue emerged while we were developing stories for the notification capability. The component needed to resolve a role into the users holding that role and then dispatch messages to them.

The individual behaviour was straightforward, but the story raised a question about a newly deployed platform. Where would the first users come from?

The platform’s seed data created services, roles, permissions and configuration. It did not create real people. As a result, every role-to-user lookup on a fresh installation would return an empty list. Notifications could be dispatched successfully from the component’s perspective while reaching nobody.

The permissions specification described how permissions would work. The notification specification described how recipients would be resolved. The seeding process correctly avoided inventing real users. What none of them defined was how the platform would move from an initialized technical state to an operational state containing its first users, or which capability owned that transition.

This was not simply an unstated assumption inside one specification. It was an unresolved part of the platform’s runtime architecture. It concerned sequencing and ownership across several modules during a particular stage in the system lifecycle.

Component specifications tend to describe steady-state responsibilities well. Story development often exposes the transitions around that steady state: initialization, deployment, migration, recovery and retirement. Those transitions may not belong to a single module, but they still require architectural decisions.

Architecture between modules and organizations

Another incident concerned how the platform’s user interface would be composed. An architectural standard written several months earlier stated that UI modules would be bundled with a common shell and released as a single artifact. The standard had been documented and referenced by several stories.

While developing a later group of UI stories, we followed the decision through to a specific customer-facing product and its release process. The consequence was that every platform enhancement added to the shared shell would require the product to redeploy, even when nothing in the product had changed.

The original rule was reasonable when considered as a mechanism for simplifying UI composition. Its cost became apparent only when the design was placed in the context of a team operating on its own delivery schedule.

We retired the rule and updated the affected parts of the architecture documentation.

The important boundary in this case was not only between software components. It was also between the platform and the teams consuming it. The technical design created an operational dependency across organizational boundaries. That dependency became visible only when the story connected an architectural standard to the release process of a particular team.

Together, these incidents show the different kinds of architectural questions that can surface when specifications are developed into buildable work. The question then becomes who is equipped to recognize and resolve them.

Design authority during story development

I use the term design authority for the function that carries this responsibility.

Design authority is not necessarily a job title. It may be exercised by an architect, a technical lead, a senior developer or a group of people with explicitly assigned responsibilities. What matters is not the title but whether the people performing the function have the capabilities required to make decisions at the level of the system rather than only within an individual story or component.

The first of these is breadth. Design authority needs a bird’s-eye view of the system described by the specifications and an understanding of how decisions within one component or feature interact with others. The notification issue could not be understood purely from the notification component, just as the UI composition issue could not be understood purely from the shell.

It also requires continuity. The significance of an architectural decision often depends on why it was made, what alternatives were considered and what conditions existed at the time. A standard read in isolation may appear absolute when it was actually a response to a particular constraint. When circumstances change, someone needs enough continuity with the architecture to recognize the difference.

Standards custody is closely related. Design authority needs to know which architectural rules and decision records genuinely govern the system, how they relate to one another and when a proposed decision conflicts with them. This becomes particularly important when AI participates in story development and review, because a plausible reference to a standard is not the same as an actual standard.

The function also requires lifecycle awareness. Architecture is experienced not only through component interactions at runtime but through initialization, deployment, migration, operations and the ways in which other teams consume the platform. Some questions become visible only when the system is viewed across those stages.

Finally, design authority requires contextual judgment, authority and accountability. Someone has to distinguish a local implementation choice from a decision with wider architectural consequences. When a conflict emerges, that person or group must be able to determine whether the story should change, whether the specification or standard should be revised, or whether an exception is justified.

These capabilities cannot simply be assumed to exist because responsibility has been assigned. Developers should develop architectural capability, and AI can help them explore systems and decisions in ways that were previously much harder. But a developer with only a few years of industry experience may not yet have had the opportunity to build a system-wide perspective, follow architectural decisions over time or experience their consequences across deployment and operations. This is a question of exposure and context, not simply individual capability.

Experience alone does not automatically create design authority either. Organizations need to understand which capabilities the function requires, develop them deliberately and ensure that they are present when architectural questions emerge.

This function also needs to be accessible while the specification is being turned into buildable work. Review only at specification approval is too early for questions that have not yet emerged, while review only at the code stage may come after a story has already embedded the wrong decision.

This does not mean that an architect must write or approve every story. Teams need a clear way to identify architectural questions during story development and bring them to someone who holds the relevant context.

AI as an assistant to design authority

AI played more than one role in this work. It helped draft the stories, but it also helped review them against the architectural specifications, standards and decision records.

That review added significant value. It found genuine omissions and raised conflicts that had not been captured in the original story drafts. Some findings could be resolved through clarification. Others required me to return to the story, reconsider the design and change the proposed approach.

The assistant was particularly useful for examining a large body of stories with greater consistency than a person could easily maintain. It could compare a story with documented standards, identify an apparent deviation and suggest alternatives. Used in this way, AI extended the reach of architectural review.

However, the review output still required judgment. A red flag could mean that the story was wrong, that the architectural standard was outdated, that the specification had left something unresolved or that the deviation was justified by context. The assistant could identify the tension and propose responses, but design authority still had to decide what the tension meant.

Two incidents illustrated this distinction.

In one batch of drafts, several stories referred to an architectural rule prohibiting a particular kind of cross-entity database join. The rule sounded credible, fitted the style of our other standards and appeared consistently across multiple sessions.

The rule did not exist.

The actual principle was narrower and concerned repository ownership rather than join semantics. The generated rule often produced an outcome similar to the real principle, which was why it survived for some time without attracting attention. Familiarity with the specifications eventually exposed the difference.

The assistant had not produced an obviously absurd answer. It had produced a plausible extension of the material around it. Had we accepted it without checking its provenance, repetition could eventually have turned a generated interpretation into what appeared to be an established architectural rule.

In another session, we were considering whether to divide a foundational story into two. The assistant argued against the split because both parts still had to be delivered sequentially. If the objective was parallel delivery, its reasoning was sound.

Parallelism, however, was not the relevant concern. Keeping the story intact created dependencies between operations in different features that did not actually depend on one another. Splitting it removed those false relationships and made the real sequence of work clearer.

The assistant had reasoned correctly within the immediate framing of the question. Reaching the appropriate decision required a wider view of the system’s dependency structure.

These examples clarify the division of responsibility. AI can surface inconsistencies, examine alternatives and extend the coverage of architectural review. Design authority interprets those findings and makes decisions in the context of the whole system.

Making the boundary visible

The boundary between what and how will exist whether an organization acknowledges it or not. The practical question is whether the decisions made there are visible and reviewable.

Three practices would have helped with the issues I encountered.

First, architectural review should be available during story development, not only before or after it. Teams need a defined route for raising decisions that affect standards, component boundaries, lifecycle behaviour or other parts of the system.

Second, material architectural assumptions should be recorded in the stories they affect. This should not become another mandatory template section. It is useful when a story depends on something the specification has not stated, such as an initialization sequence, an upstream capability, a deployment condition or ownership of a cross-module interaction. Recording such assumptions gives reviewers something concrete to examine.

Third, architectural rules cited in stories should be traceable to a specification, an architectural decision record or another recorded decision. If no source exists, the rule should be treated as a proposal requiring review. This prevents a plausible generated interpretation from acquiring authority merely through repetition.

AI can support all three practices. It can classify potential architectural questions, compare assumptions across stories and validate references against the available documentation. The resulting workflow combines the tool’s ability to process a large volume of material with the contextual judgment and accountability of design authority.

A limitation in my own approach

During this work, I held both the architect and design-authority roles. I had written most of the specifications, maintained the standards and decision records, and followed the platform from its earlier stages. I therefore had the system-wide view represented in the specifications, the continuity behind earlier decisions and the authority to revisit them when the stories exposed a problem.

That combination helped me identify and resolve many of the issues described here. But working through such a large body of stories also exposed the other side of concentrating this responsibility in one person: the cognitive load can become significant. Holding the wider system context, the history behind earlier decisions, the relationships across specifications and the consequences of new decisions in mind while continuously reviewing and refining stories is difficult to sustain.

There is also an organizational dependency. A platform should not depend on one person remembering what every decision meant and why it was made. If architectural coherence resides mainly in one person’s memory, the organization has created a dependency rather than a sustainable design function.

The responsibility can be shared, but it should not be ambiguous. A more sustainable approach would distribute architectural knowledge while making clear who holds the relevant context, who can change an architectural decision and where the reason for that change will be recorded. The objective is not to centralize every choice, but to prevent system-wide decisions from being made accidentally within isolated stories.

AI can make the underlying architectural material easier to search and review, but it does not resolve the cognitive load, responsibility or accountability that comes with design authority.

Conclusion

Developing nearly 190 stories did not teach me that specifications leave implementation decisions open, or that detailed engineering work can cause architectural decisions to evolve. Those are familiar parts of software architecture.

What the experience made much more visible was the design-authority function operating in that space, and how much that function depends on capabilities that can easily be taken for granted.

The incidents described here required different forms of architectural judgment. Some required a view across components, some required knowledge of the system lifecycle, some depended on the history behind an earlier standard, and others required deciding whether an AI-generated finding represented a genuine architectural issue at all. The common factor was the need for someone with enough context to understand the consequence and enough authority to act on it.

AI was valuable throughout this process. It helped create the stories, review them, identify gaps and suggest alternatives. It can extend both the depth of exploration available to developers and the reach of architectural review. But increasing the speed and scale of those activities does not by itself provide the system-level context or accountability needed to govern the decisions that emerge from them.

This is why I believe design authority deserves more explicit attention in AI-assisted ways of working. The function may sit with an architect, a senior engineer, a technical lead or a small group. What matters is that organizations understand the capabilities it requires, develop those capabilities deliberately, and ensure that the function is present where the what meets the how.

© 2025-2026 Anand Saranath - All rights reserved