The Application Is Disposable. The Context Is Not.

I needed a small application.

An enterprise architecture and governance group needed a structured way to explain how it actually operates.

Not where its documents were stored.

Not which Confluence pages existed.

Not how many PowerPoint decks had accumulated in SharePoint.

I needed to understand the group’s operating semantics:

• What decisions do they make?
• What questions do they ask?
• What evidence do they require?
• Which terms have precise meanings?
• Who owns those meanings?
• Which other teams do they depend on?
• What happens when two sources disagree?
• Which requirements are product-independent?
• Which documents are authoritative, advisory, historical, or simply wrong?

This was not a document-ingestion problem.

It was an institutional-meaning problem.

The people involved needed help extracting that meaning. Most of them were not ontology engineers. They should not have to understand semantic modeling, provenance, lifecycle design, or graph relationships before they could explain how they do their jobs.

So I needed a guided interview application.

The normal enterprise response would have been predictable.

Create a SharePoint site.

Design a List.

Build a Microsoft Form.

Perhaps build a Power App.

Connect it to Dataverse.

Add a Power Automate flow.

Request an environment.

Resolve licensing.

Configure permissions.

Work through platform governance.

Decide who supports it.

Determine whether it belongs in Teams.

Hold several meetings about whether the existing platform can technically do what everyone already knows it can technically do.

Then, somewhere between the fifth meeting and the second requirements spreadsheet, the original need quietly loses the will to live.

I did something different.

I described the institutional semantics as code.

Then I let agents manufacture the application around them.

The application used to be the asset

Traditional application development assumed implementation was expensive.

Once an organization had spent months gathering requirements, obtaining funding, configuring infrastructure, writing code, testing integrations, and completing governance reviews, the resulting application became something to protect.

That made sense.

The application represented a substantial concentration of labor, calendar time, specialized knowledge, and institutional negotiation.

Even an ugly internal tool became durable because replacing it was painful.

That economic assumption is beginning to fail.

When a sufficiently clear context can be projected into a working application by agents, the code is no longer the only scarce artifact.

Often, it is not even the most important one.

The durable asset becomes:

• the domain vocabulary;
• the definitions;
• the relationships;
• the decision rules;
• the authority model;
• the evidence requirements;
• the lifecycle;
• the conflict rules;
• the validation cases;
• the human approvals;
• the interface contracts.

The application becomes one representation of those things.

It may still be important.

It may still require security review, testing, operational ownership, and support.

But it does not necessarily deserve to become permanent merely because someone built it.

Compliance can improve

There will be an immediate objection:

We cannot do this because we are regulated.

That conclusion is backwards.

A regulated organization should care deeply about:

Context as code can make those things more visible, not less.

The semantics can specify:

• which controls apply;
• what evidence is mandatory;
• who may approve;
• which changes require escalation;
• which data classes are permitted;
• which deployment profiles are authorized;
• which tests must pass;
• what must remain unresolved.

The agents do not become the authority.

They perform the projection work inside the authority model.

That is a much stronger pattern than burying critical business meaning inside a Power App formula, a SharePoint column, a Confluence page, a developer’s memory, and three email threads that everyone hopes remain searchable.

What service owners should maintain

The service area of the future should not spend most of its energy maintaining individual forms.

It should maintain the meaning from which forms can be generated.

That means preserving:

• its ontology;
• its vocabulary;
• its decision rules;
• its authority boundaries;
• its evidence standards;
• its dependencies;
• its exceptions;
• its validation cases;
• its integration contracts;
• its deployment constraints.

That is harder than configuring a form.

It is also more valuable.

A poorly defined ontology will allow agents to manufacture incorrect applications with extraordinary speed.

AI does not remove the need for semantic discipline.

It makes the absence of semantic discipline operationally expensive.

The faster the factory becomes, the more important the blueprint is.

The industry is converging on pieces of this

I am not making this argument in a vacuum.

OpenAI's own harness-engineering work describes a team that made repository knowledge the system of record, treated context as an engineering resource, and shifted human effort toward specifying intent, designing the environment, and constructing feedback loops while agents performed more of the implementation.

Anthropic has arrived at a related conclusion from another direction. Its work on context engineering treats the surrounding context state, tools, history, and external information as the real steering problem for capable agents. Its guidance for long-running agents depends on durable artifacts and explicit handoffs because the worker cannot be trusted to carry continuity across context resets by itself.

Google DeepMind's AlphaEvolve demonstrates another part of the pattern. Models generate candidate programs, automated evaluators judge them, and the system iterates against explicit objectives. Implementation becomes increasingly manufacturable when the objective and evaluation machinery are clear enough.

NIST supplies the control boundary. Secure software development still requires documented requirements, recorded design decisions, component provenance, verifiable processes, and human validation of AI-generated work. Faster generation does not eliminate lifecycle or authority. It makes those controls more important.

These sources do not prove the complete doctrine in this article.

None of them says an enterprise should treat its applications and databases as disposable projections from governed institutional semantics.

That synthesis is the argument I am making here, and the CBT Context-as-Code Collection Lab is the concrete case behind it.

The industry is converging on the components: implementation is becoming cheaper, context and system design are becoming more valuable, durable artifacts are required for continuity, automated evaluation can govern generated work, and human authority remains necessary.

The next architectural step is to join those components deliberately.

That is where this article goes further.

A different software portfolio

Most organizations manage applications as durable inventory.

Each application receives:

• a name;
• an owner;
• a budget;
• a platform;
• a support model;
• a roadmap;
• a retirement plan that is usually interpreted as a theoretical concept.

Context as code suggests a different portfolio model.

The organization can distinguish:

The doctrine

The lesson is not that everyone should stop using SharePoint.

It is not that Power Apps, Dataverse, Confluence, Tableau, Teams, Azure, or Microsoft 365 have become obsolete.

It is that those platforms should no longer determine what the organization is capable of expressing.

Once the semantics are governed as code, the organization can project them wherever they belong.

The application may run on Cloudflare today and Azure tomorrow.

The shared store may be D1, PostgreSQL, Azure SQL, Dataverse, or something else.

The user experience may be a web application, a Power App, an agent conversation, a printable workbook, or all four.

The meaning remains stable.

The projections change.

That is the new leverage.

Projection Factory doctrinePreserve the meaning. Generate the software. Retire the projection when its job is done.

PreserveGenerateRetire