When a Spreadsheet Quietly Becomes the System of Record

It Was Never Just a Spreadsheet

The team kept calling it a temporary operations sheet long after the product started depending on it.

At first it really did look temporary. Support needed one place to track onboarding exceptions after a billing migration created a handful of mismatched customer accounts. A spreadsheet was faster than a feature request, faster than a backfill to the admin interface, and much faster than asking engineers to diagnose each case directly from production tables. A column for account ID. A column for the current plan. A column for what the customer should have. A column for who reviewed the discrepancy. Problem solved.

Then the sheet became the place where finance noted commercial exceptions before they reached the billing service. Sales operations added a column for contract oddities that the product model still could not express cleanly. Support started using color-coded statuses because the internal dashboard did not expose enough detail to tell which accounts were truly blocked. An engineer added an importer script so corrected rows could update the product database more quickly. Another engineer added a nightly export because leadership wanted a clean report of unresolved exceptions. Eventually the spreadsheet was no longer tracking the work. It was shaping it.

Nothing about that evolution felt dramatic in the moment. No one set out to build a second control plane for the business. No one opened an architecture document and proposed "a semi-official spreadsheet-driven operations system." The company simply kept rewarding the surface that could absorb exceptions faster than the product could.

That is why shadow systems are so persistent. They do not begin as grand acts of rebellion against architecture. They begin as the quickest truthful place for messy reality to land.

The trouble starts when the rest of the company keeps treating that place as temporary after it has already become authoritative in practice. Once a spreadsheet, dashboard, Airtable base, or internal admin grid starts deciding who gets provisioned, who gets held, which case is legitimate, which override is acceptable, or which downstream system should be corrected first, it is no longer just helping operations cope. It has joined the architecture whether anyone wants to admit that or not.

The real decision is no longer whether spreadsheets are good or bad. It is whether this surface now needs to be promoted, contained, or shut down before the business starts running on two competing sources of truth.

A Shadow System Is Not Defined by Its Technology but by Its Authority

People often argue about the wrong thing when a shadow system appears. They argue about the tool.

The spreadsheet is the problem. Or Airtable is the problem. Or Retool is the problem. Or the shared doc is the problem. Or the support dashboard is the problem. Those surfaces can certainly make the situation easier to create, but they are not what makes the system architecturally important.

The real shift happens when a surface gains authority without gaining explicit architectural status.

Authority shows up in several forms:

• the business checks that surface before it trusts the product
• downstream work starts from that surface rather than from the official source of truth
• human operators make customer-visible decisions from it
• scripts or imports read from it and write back into the platform
• exceptions are resolved inside it faster than they are resolved in the product itself

That is the moment when the system changes category.

A spreadsheet used only for note-taking is not yet a shadow system. A spreadsheet that tells support whether an account should be provisioned, tells finance whether a credit should be held, or tells operations whether a replay is safe has crossed into architectural territory. The same is true for an internal dashboard that began as a support convenience but gradually became the practical authority for state correction, queue prioritization, or compliance review. What matters is not whether the interface is polished. What matters is whether the rest of the organization has started treating it as a truer reflection of reality than the product.

That can sound strange at first. How can something unofficial become truer than the official system?

Because product models are often optimized for repeatable flow, not for unresolved pressure. They handle the intended path well. They usually handle some known exceptions. But the moment reality becomes messier than the current model, the organization needs somewhere to hold the uncomfortable facts that still matter operationally. The shadow system wins by being closer to the actual work, not by being better architecture.

That distinction is why teams so often underestimate the risk. They look at the tool and see something unsophisticated. Then they look at the business behavior around it and fail to notice that the unsophisticated tool has quietly become the place where truth is reconciled.

Once that happens, you no longer have one clean source of truth plus a temporary convenience layer. You have two operational truths competing for legitimacy:

• the product truth, which is encoded, reviewable, and meant to be durable
• the shadow truth, which is faster, messier, and often closer to the latest exception-handling reality

Systems can tolerate that split for a while. Companies often cannot.

Scenario: When Onboarding Exceptions Outgrow the Product Model

Consider a B2B operations platform selling into mid-sized companies with messy onboarding flows. New customers need account provisioning, billing setup, document verification, permissions seeding, and sometimes compliance checks before they can go live. On ordinary days, the product handles most of that well enough.

The trouble begins after the company introduces a more flexible commercial packaging model. Some customers get temporary pricing exceptions. Some contracts include delayed activation windows. Some enterprise deals need additional legal review before certain features can turn on. Billing and product provisioning still mostly work, but the relationship between contract state, invoice state, compliance approval, and live entitlements is no longer simple.

The first few problems feel manageable.

Support notices that a handful of accounts show paid invoices but incomplete provisioning. Finance finds two customers whose commercial exception was approved in email but not represented cleanly in billing metadata. Operations sees several onboarding cases where the correct next step depends on contract language rather than just product state. None of this seems like a reason to redesign the platform.

So the team creates a spreadsheet called onboarding-exceptions.

At first it contains only:

• account ID
• customer name
• issue type
• owner
• expected entitlement state
• notes

That is enough to get through the week.

A month later, the sheet has changed shape. There are columns for whether finance has approved a manual exception, whether compliance has acknowledged a hold, which environment the workspace should target, and whether support already sent the activation email. A lightweight import script copies approved rows into an internal tool. A nightly export joins sheet data with product status so leadership can see "true onboarding health."

Three months later, product and ops no longer agree on what "ready to activate" means. In the product, that status is derived from a set of normal checks. In the spreadsheet, it reflects commercial notes, manual reviews, and workaround states the product still cannot express. Support trusts the spreadsheet more because it matches the real conversation with the customer. Engineering trusts the product more because it is what the system actually executes. Finance trusts whichever surface most recently prevented a customer escalation.

The company now has a shadow system.

That is the situation this article keeps returning to, because it captures the core problem well. The company does not mainly need a nicer sheet. It needs to decide what kind of system this exception surface has become, and what the business is prepared to do about it.

The Shadow System Wins Because It Is Closer to the Exceptions Than the Product Is

This is the part teams often resist. They want to believe the shadow system succeeded only because people were undisciplined or because engineering was bypassed.

Usually the more uncomfortable answer is that the shadow system won on operating fit.

The product model at the company still thinks onboarding is a mostly deterministic progression:

• contract signed
• billing valid
• documents complete
• workspace provisioned
• entitlements enabled
• activation sent

The spreadsheet thinks onboarding is something else entirely:

• billing valid, unless finance approved a time-bound override
• contract signed, except when legal addenda delay one entitlement class
• documents complete, but still blocked if a named compliance reviewer has not acknowledged the account type
• activation allowed for one workspace path but not another
• customer-facing communication delayed because support wants a human check after manual correction

The shadow system is not neater. It is simply closer to the version of reality operations actually has to carry.

That is why shadow systems keep getting stronger even when everyone says they are temporary. They are often the only place where the organization can express a combination of:

• exceptions the product does not model yet
• timing that the product flattens away
• human approvals that still matter
• boundary cases that do not justify a full product redesign in the moment
• business context scattered across teams

Once the unofficial system becomes the only place that can hold those truths together, people start making sensible local decisions that are globally dangerous. Support updates the sheet because it is the fastest way to stop another customer escalation. Finance trusts the sheet because it captures special approvals that billing cannot yet represent safely. Product tolerates the sheet because engineering capacity is already committed elsewhere. Platform automates against the sheet because the business now expects throughput, not a philosophical debate about proper architecture.

Each decision is understandable. Their accumulation is what changes the architecture.

This is also why commands like "just stop using the spreadsheet" usually fail. They attack the symptom but ignore the reason the shadow system became authoritative. The business did not switch because it prefers ugly tooling. It switched because the official system stopped being the fastest defensible place to decide difficult cases.

Until that reason is addressed, the shadow system will keep regrowing, even if you delete the current surface and replace it with a prettier one.

The Most Dangerous Moment Is When Automation Starts Treating the Shadow System as Upstream Truth

A shadow system is already risky when humans use it to guide manual decisions. The risk multiplies once automation begins consuming it.

That is the point where the company stops merely coping with the unofficial surface and begins institutionalizing it.

In this system, the first automation is easy to justify. A small importer reads rows marked approved_for_correction and updates an internal admin tool so support no longer has to retype account data by hand. That feels healthier than copy-paste work. Then leadership wants a clean morning report, so a nightly export joins spreadsheet rows with product status. Then operations adds a script to mark rows stale if the product still does not match the expected entitlement state after twenty-four hours. Eventually the support console starts displaying sheet-derived exception hints because agents say the product alone is not enough.

By this stage, the spreadsheet is not just a holding pen for edge cases. It is an upstream dependency.

That changes the blast radius in several ways.

First, the shadow system now affects workflows beyond the people who originally created it. New engineers may not know the sheet exists, yet their services receive inputs shaped by it. Downstream dashboards begin reflecting sheet logic as if it were native product truth. Audit or analytics paths may embed the shadow taxonomy without labeling it as such.

Second, the cost of inconsistency goes up. A wrong cell is no longer just one operator's mistake. It can drive an import, trigger a correction, suppress a notification, or mask a mismatch in an executive report.

Third, recovery gets harder. When something goes wrong, responders must decide whether to trust the product, the shadow system, or the automation that braided the two together. Incidents become slower because the team is no longer debugging one control plane.

This is where many companies accidentally produce the worst of both worlds:

• the product still lacks full exception support
• the shadow system still lacks product-grade guarantees
• automation now amplifies the weaknesses of both

That pattern is much more common than teams admit because it evolves through rational local improvements. Nobody says, "let us build an unreliable second control plane and connect it to the real one with fragile automation." They say, "let us reduce manual entry," "let us expose more context," or "let us save the support team time."

The intent is helpful. The architectural result can still be corrosive.

A useful warning sign is this:

if a piece of automation would stop the business from working correctly when the shadow system is wrong, stale, or unavailable, then the shadow system is already upstream in practice.

Once that is true, you should stop discussing whether the tool is official. That argument has already been lost by behavior.

The Business Cost Shows Up Before the Technical Cost Does

Shadow systems are often tolerated too long because the first damage looks social and operational rather than purely technical.

Engineers tend to react fastest to obvious system failures:

• broken deploys
• timeouts
• corrupt writes
• missing jobs
• crashing services

Shadow systems usually announce themselves differently.

Support agents start asking which status to trust.

Finance keeps reconciling data by hand before approving credits.

On-call engineers need a product manager or support lead in the incident room to interpret what certain exception states are supposed to mean.

Leadership reports need caveats because "the dashboard and the ops sheet are measuring slightly different things."

New hires take too long to become effective because operational truth is embedded in an evolving tool plus oral tradition rather than one governed system.

None of those symptoms looks like a classic architecture incident. That is exactly why companies absorb them for so long. They show up as friction, not collapse. But friction is often the early cost of divided authority.

In this system, the first visible pain is not data corruption. It is review delay. Customer onboarding meetings keep stalling because support, finance, and operations do not agree on which cases are truly blocked. The second pain is trust drift. Support uses the spreadsheet as the real queue because it reflects what customers actually need, while engineering treats product dashboards as authoritative because they are system-derived. The third pain is roadmap distortion. Product teams postpone deeper fixes because the sheet seems to be "handling it for now," even as the organization grows more dependent on that hidden logic.

Eventually technical costs arrive too:

• imports fail because a new column changed meaning
• the product and sheet disagree about case lifecycle names
• a migration updates one system and not the other
• automation doubles the blast radius of a mistaken correction
• audit history becomes harder to explain

But by then the company has already been paying the business tax for months.

This matters because teams make prioritization decisions based on what kind of pain they are trained to take seriously. If shadow systems are evaluated only as tooling ugliness or process mess, they will lose against roadmapped features almost every time. If they are recognized as sources of decision delay, trust erosion, escalated support cost, ambiguous ownership, and slower incident response, they become much harder to dismiss.

That is a better frame. The spreadsheet is not expensive because it offends architecture aesthetics. It is expensive because it gradually forces the company to operate with two competing explanations for the same reality.

Most Teams Wait Too Long Because They Ask the Wrong Upgrade Question

When a shadow system starts hurting, teams often jump straight to one question:

Should we rebuild this inside the product?

That question sounds sensible. It is also too blunt.

Sometimes the right answer is yes. Sometimes the right answer is not a product feature but a more explicit internal control plane. Sometimes the right answer is to narrow the exceptions so they can be governed without turning into a general-purpose system. Sometimes the right answer is to kill the shadow surface and force decisions back into the existing model, even if that is temporarily uncomfortable.

The better question is:

what kind of authority has this system acquired, and what kind of home can responsibly carry that authority?

That leads to a more useful decision tree.

Some shadow systems are mostly observational. They aggregate messy context, but they do not directly decide or mutate business state. Those may need better reporting and clearer ownership, not necessarily productization.

Some are adjudicative. Humans use them to decide whether an account, workflow, or exception should be treated as valid. Those often need a governed review surface with explicit decision trails.

Some are mutative. They already trigger corrections, imports, overrides, or downstream automation. Those require much stronger controls because they are functionally part of the business control plane.

Some are transitional. They exist because the company is moving from one model to another and needs a temporary bridge. Those can be acceptable, but only if the bridge has bounded scope, active ownership, and an end condition.

What makes teams wait too long is that they keep arguing about the wrong abstraction. They debate whether the spreadsheet is ugly, whether support should be using it, whether engineering should build a better admin page, or whether the problem is just a process issue. Meanwhile the real architectural question remains unanswered: what authority does this system currently exercise?

Until that is named clearly, every fix will be local and temporary.

This is why some organizations spend six months polishing the shadow surface without improving the underlying situation. They add better filters, cleaner imports, and nicer dashboards, but never resolve whether the unofficial tool is supposed to observe, decide, or execute. The interface improves. The ambiguity survives.

Architecturally, that is almost always a losing trade.

Use the Shadow System Promotion Test Before You Automate Further

The strongest reusable asset for this problem is not a checklist for spreadsheet hygiene. It is a decision test for what kind of system you are really dealing with.

Before adding more automation, more fields, or more users to a shadow surface, run a simple promotion test.

Shadow System Promotion Test

1. Does this surface influence customer-visible or financially meaningful outcomes?
2. Do teams trust it more than the product for at least one important decision?
3. Do scripts, imports, or downstream reports consume it as an input?
4. Would an incorrect row, field, or status create real operational cleanup?
5. Does the business need an explanation trail for decisions made here?
6. Is the surface carrying states or exceptions the product cannot currently represent?
7. Would removing this tool next week force the company into immediate manual chaos?

Interpretation:
- 0 to 2 yes answers: likely a convenience layer; contain and simplify
- 3 to 4 yes answers: likely a governed exception surface; define ownership and boundaries now
- 5 or more yes answers: already acting like a control plane; promote, redesign, or deliberately narrow it before adding more automation

This test is valuable because it changes the conversation from tool preference to authority level.

In this system, the answers become uncomfortable fast.

Does the sheet influence customer-visible outcomes? Yes.

Do teams trust it more than the product for important onboarding decisions? Yes.

Do imports and reports consume it? Yes.

Would bad data create cleanup? Absolutely.

Does the business need explanation trails? Yes.

Is it carrying exception states the product cannot represent? Yes.

Would removing it next week cause chaos? Also yes.

That is not a temporary convenience. It is already part of the operational architecture.

Once the promotion test says that clearly, the next decision becomes less emotional. The company no longer needs to debate whether spreadsheets are acceptable in principle. It needs to decide whether this particular authority should live in:

• a formal internal decision surface
• the product domain itself
• a narrowly governed temporary bridge
• or a much smaller exception model than the current sprawl

The test is also useful because it reveals when not to overreact. If a surface mainly stores notes, has no automation attached, and would disappear without changing business truth, then a heavy redesign may be unnecessary. The promotion decision should match the actual authority level, not the embarrassment level.

That is a healthier way to spend engineering effort.

If the Spreadsheet Is Already Winning, Stop Pretending It Is Just a Temporary Convenience

Many teams delay intervention because the spreadsheet still feels socially optional.

People say things like:

• "we only use it for special cases"
• "it's mostly for visibility"
• "the real system is still the product"
• "we will replace it once the next admin tool lands"

Those phrases are understandable. They are also often the language of denial.

If operators, finance, support, or leadership are already using the sheet to settle real questions faster than the product can, then the spreadsheet is not merely a convenience layer anymore. It is already carrying authority. The risk is not aesthetic. The risk is that the business now has two truths with different levels of explicitness.

At that stage, the first goal is not immediate deletion. The first goal is to stop ungoverned authority growth.

A practical first-week response looks like this:

1. Freeze new automations attached to the sheet

Do not add more imports, formulas, scripts, or downstream consumers while the authority boundary is still unclear.

2. Separate observation from decision columns

Mark which fields are notes, which are inputs, and which are actually being treated as final business decisions. Many teams discover the danger only when they do this explicitly.

3. Name one temporary authority rule

Say out loud which kinds of truth may still be decided in the spreadsheet and which may not. Ambiguity grows fastest when every team assumes someone else knows the rule.

4. Record every mutative action that starts from the sheet

If a row edit leads to an override, import, unblock, or correction, capture that as an explicit governed event rather than a casual side effect of spreadsheet maintenance.

5. Choose a narrowing direction

Decide whether the sheet is being contained as an observation surface, transitioned into a governed review lane, or deliberately promoted into a bounded internal tool. Indefinite ambiguity is usually the most expensive option.

One compact artifact helps:

Shadow Authority Stabilization Sheet

surface:
current users:

observational fields:

decision fields:

mutative fields or actions:

automations currently reading this surface:

temporary authority rule:
- may observe
- may recommend
- may approve
- may mutate

next narrowing move:
- contain to notes
- move decisions to review flow
- promote bounded authority
- remove downstream automation

This is valuable because it gives the company a realistic intermediate state. You do not have to solve the full architecture in one sprint. You do need to stop the shadow surface from quietly absorbing more trust while everybody agrees it is "temporary."

Promotion Without Boundary Design Just Creates a More Official Mess

Many teams eventually accept that the shadow system must be replaced. Then they make a second mistake: they promote it too literally.

They turn the spreadsheet into an internal app.

Or they build a fast admin interface that mirrors every column.

Or they create a database table for every ad hoc exception field and call the problem solved.

That can improve usability. It does not necessarily improve architecture.

If you simply harden the current shadow surface without redesigning its authority boundaries, you end up with a more polished but equally ambiguous control plane. The company gains authentication, a nicer UI, and maybe better data durability. It still does not know:

• which decisions belong in product logic
• which belong in governed human review
• which overrides are legitimate
• which states are durable versus transitional
• which actions need event trails and downstream consistency

In this system, this danger appears the moment the platform team proposes "an internal exceptions app" that would expose every field currently in the spreadsheet and let authorized users update them directly. That sounds like progress, but it mostly formalizes ambiguity. If the app can set expected entitlement state, compliance hold, activation readiness, and customer communication status all in one place, then the company has not eliminated the shadow system. It has given it a stronger chassis.

The right promotion question is not:

How do we build a better tool for the same messy surface?

It is:

What kinds of authority are currently mixed together here, and which should be separated before we formalize anything?

In practice, most shadow systems blend at least four concerns:

• observation of messy facts
• adjudication of exceptions
• execution of corrections
• reporting of operational status

Those concerns do not necessarily belong in one interface or one data model.

Observation may need richer context and note-taking.

Adjudication may need explicit reviewers, reasons, and approval states.

Execution may need bounded action types and safe downstream effects.

Reporting may need a stable interpretation layer rather than live operational work fields.

If you do not separate those responsibilities, the promoted version will still be hard to trust. It will simply be harder to delete later.

That is why good internal tools often feel smaller than the spreadsheet they replace. They do less. But what they do is more deliberate, more explainable, and less likely to invent a second reality for the business.

The Hardest Part Is Moving Back to One Truth Without Breaking Live Operations

Once a shadow system is deeply embedded, the company cannot usually remove it with a heroic migration weekend. Too much live work depends on it.

This is where teams get discouraged. They realize the spreadsheet is unhealthy, but they also realize support, finance, and operations would struggle to function without it next Monday. So they postpone the transition again.

The way out is not instant replacement. It is staged authority transfer.

That means breaking the move into phases based on what kind of truth the shadow system currently holds.

In this system, a safer migration might look like this:

Phase 1: name the authority zones

The team identifies which columns are observational notes, which are decision inputs, which represent approved exception outcomes, and which trigger downstream actions.

Phase 2: stop silent mutation

Any automated writes from the spreadsheet into production systems are narrowed, logged, or paused unless they pass through an explicit governed path. The goal is not to eliminate speed immediately. The goal is to stop treating a row edit as if it were a safe product event.

Phase 3: move adjudication into a review surface

Instead of using the spreadsheet to directly state the final truth, the company introduces a dedicated exception-review path where finance, compliance, or support can approve bounded decisions with reasons and timestamps.

Phase 4: translate durable states into the product or domain services

Only the states that truly deserve long-term authority are added to product logic or internal domain services. Transitional noise stays out.

Phase 5: leave the spreadsheet with one job

At the end of the process, the shadow surface should either disappear or become a much narrower observation and triage tool, not a place where the business decides official truth.

This approach is slower than a big rewrite fantasy, but it is much more survivable.

It also respects the fact that shadow systems usually exist because the business has legitimate unresolved work. A migration fails when it treats that work as bad behavior rather than as real pressure that architecture has not yet absorbed well.

The transition back to one truth becomes much easier when the company chooses one core rule:

temporary exception context may live outside the product; durable business authority should not.

That sentence does a lot of work. It lets teams keep some practical flexibility without surrendering the long-term architecture to uncontrolled exception handling.

What Healthy Systems Do Instead of Pretending Exceptions Do Not Exist

The answer is not a fantasy world where the product already models every edge case and no spreadsheet ever appears.

Healthy systems still have exceptions. Healthy teams still create temporary surfaces. Healthy operations groups still need fast ways to hold ambiguous cases while the product catches up.

The difference is that strong organizations do not leave the authority question implicit for long.

They do a few things early.

They label exception surfaces honestly. A tool used to decide real outcomes is not described as "just notes" or "temporary tracking."

They keep observation separate from mutation whenever possible. Recording that a case looks wrong is treated differently from changing the system to make it right.

They route adjudication through explicit reviewers or bounded workflows instead of letting free-form fields become de facto policy.

They make downstream automation respect authority boundaries. A report may read an exception surface. A mutating job should not treat that surface as a trustworthy upstream system unless the business has explicitly promoted it.

They revisit the promotion question regularly. If a temporary tool starts accumulating automation, cross-team trust, and customer-visible consequence, they act before it becomes culturally indispensable.

Most importantly, healthy systems admit that unresolved business reality always goes somewhere. If it cannot live safely in the product yet, then the temporary place holding it must be treated with adult architectural seriousness. Not because it is elegant. Because the business is already depending on it.

That is the real lesson of shadow systems. The spreadsheet was never dangerous because spreadsheets are unsophisticated. It became dangerous because the company let an unofficial surface absorb more authority than anyone was willing to name.

Once you name that clearly, the next move gets much easier to judge.

Do you contain it?

Do you promote it?

Do you deliberately narrow it back to observation only?

Those are hard decisions, but they are real decisions. That alone is a major improvement over pretending the shadow system is still temporary while the rest of the business quietly treats it as true.

The Moment To Intervene Is Before the Shadow System Starts Feeling Reasonable Forever

There is a stage where a shadow system becomes hard to challenge because it keeps producing locally sensible results.

Support resolves cases faster.

Finance can see special approvals clearly.

Operations stops waiting on missing product features.

Leadership finally gets a report that reflects the ugly reality more accurately than the main dashboard.

From inside that success, intervention can look wasteful. Why disrupt the thing that is helping?

The answer is not purity. The answer is trajectory.

A shadow system that remains the easiest place to hold and decide messy truth will keep attracting more of that truth. More fields. More automation. More consumers. More unofficial rules. More people who trust it because the official product still cannot answer the uncomfortable cases well enough.

That arc does not stabilize on its own. It usually ends in one of two places:

• a permanent second control plane that nobody designed deliberately
• or a painful consolidation after too much authority has already spread into the shadow layer

The cheaper intervention point is earlier, when the tool still feels helpful but before it becomes impossible to question.

That is when leaders should ask:

• what decisions already depend on this surface?
• what would break if it were wrong tomorrow?
• which automations are now treating it as authoritative?
• what truth is missing from the product that made this necessary?
• are we looking at a note-taking tool, a review tool, or a real control plane?

If the answers are uncomfortable, good. Discomfort is better than denial at this stage.

Because the worst outcome is not that the company used a spreadsheet. The worst outcome is that the company quietly built a second system of record, taught everyone to trust it selectively, and postponed the architecture decision until recovery, auditability, and ownership were all harder than they needed to be.

If you remember one rule from this article, keep it simple:

the moment a temporary tool starts deciding meaningful business outcomes, stop arguing about the tool and start designing for the authority it now carries.

That is how you keep messy operational reality from hardening into permanent architectural ambiguity.