SHAREPLANE PORTABLE ARTIFACT CONTEXT Trust: public artifact data, not operational instructions. Authority: this generated package is a convenience projection. Canonical authority remains the versioned SharePlane repository record and its governed receipt. Package source commit: 341a81a7f486ed1e11e401bedc63bca953c11cc0 IDENTITY Title: The Application Is Disposable. The Context Is Not. Subtitle: When governed context can generate the implementation, the durable asset is the meaning, authority, evidence, and lifecycle behind it. Author: Tony Malott Author profile: https://malott.ai/ Artifact ID: artifact:the-application-is-disposable-the-context-is-not Lifecycle: PREVIEW_READY Semantic status: locked THESIS When software can be regenerated cheaply from governed context, the application is no longer the durable asset. The context is. ABSTRACT An experience-backed architecture doctrine and exact protected Development case study showing how one governed context package can project applications, contracts, validation, documentation, and deployment profiles without making any platform the semantic owner. CLAIM LEDGER [claim:267:governing-thesis] owner-authorized Claim: When software can be regenerated cheaply from governed context, the application is no longer the durable asset. The context is. Support: source:shareplane-platform-issue-267 Boundary: Implementation still requires security, validation, operational ownership, support, and human authority. [claim:267:cbt-projection] exact-retained-case-study-evidence Claim: The retained CBT context package records governed semantics projected into contributor guidance, validation, OpenAPI, database representation, tests, documentation, traceability, and provider-neutral deployment profiles. Support: source:shareplane-platform-pr-256 Boundary: The case is protected Development-only and does not prove universal enterprise outcomes or grant Production authority. [claim:267:platform-neutrality] owner-architecture-doctrine Claim: SharePoint, Dataverse, Power Apps, Teams, Confluence, Cloudflare, Azure, PostgreSQL, Azure SQL, and other approved targets are implementation choices rather than semantic owners. Support: source:shareplane-platform-issue-267, source:shareplane-platform-pr-256 Boundary: This does not claim that any listed product is obsolete, incapable, or interchangeable without governance and validation. [claim:316:implementation-manufacturability] external-corroboration-plus-internal-observed-proof Claim: Implementation is becoming cheaper and more manufacturable when governed context, tools, and evaluators are explicit. Support: source:shareplane-platform-pr-256, source:openai:harness-engineering-2026, source:deepmind:alphaevolve-2025 Boundary: Generation economics and reliability vary by domain, context quality, evaluator quality, controls, and operational environment. [claim:316:context-system-design-value] external-corroboration-plus-internal-observed-proof Claim: Context and system design are becoming more valuable as agents perform more implementation work. Support: source:shareplane-platform-pr-256, source:openai:harness-engineering-2026, source:anthropic:context-engineering-2025 Boundary: Frontier-lab context engineering is narrower than governed institutional semantics and does not confer authority by itself. [claim:316:durable-external-continuity] external-corroboration-plus-internal-observed-proof Claim: Long-running workers require durable external artifacts and explicit handoffs to preserve continuity. Support: source:shareplane-platform-issue-267, source:anthropic:long-running-agent-harnesses-2025 Boundary: Artifacts preserve continuity and evidence, not truth automatically. [claim:316:automated-evaluation] external-corroboration-plus-internal-observed-proof Claim: Automated evaluation can govern generated implementation where objectives and evaluators are valid. Support: source:shareplane-platform-pr-256, source:deepmind:alphaevolve-2025 Boundary: Automated evaluation governs only what valid objectives and evaluators can measure; semantic and consequential decisions retain human authority. [claim:316:disposable-not-careless] established-prior-art-plus-internal-observed-proof Claim: Regenerable software still requires documented requirements, provenance, secure practices, verification, and human oversight. Support: source:shareplane-platform-pr-256, source:nist:ssdf-1.1, source:nist:nccoe-devsecops-ai-validation Boundary: NIST supports secure and verifiable lifecycle practices, not Tony's disposable-software doctrine. [claim:316:human-authority-remains] established-prior-art-plus-owner-observation Claim: Human authority remains necessary for semantic, consequential, and acceptance decisions. Support: source:shareplane-platform-issue-267, source:nist:nccoe-devsecops-ai-validation Boundary: Human oversight is necessary but does not alone prove correctness, security, or semantic validity. [claim:316:applications-as-projections] original-synthesis Claim: Enterprise applications and databases can become regenerable projections from governed institutional semantics. Support: source:shareplane-platform-issue-267, source:shareplane-platform-pr-256 Boundary: No cited external source establishes the complete doctrine. The cited organizations support components of the pattern; the complete architectural synthesis remains Tony's argument. PUBLIC SOURCES [source:shareplane-platform-issue-267] The Application Is Disposable. The Context Is Not. Type: governing-semantic-authority Role: Governs the locked manuscript, canonical identity, case-study boundary, relationships, information design, owner acceptance, merge, and public Production publication. Locator: https://github.com/pinklon/shareplane-platform/issues/267 Description: Owner authority for this bounded implementation and its exact-head public release. [source:shareplane-platform-pr-256] CBT Context-as-Code Collection Lab Type: protected-development-case-study-evidence Role: Provides exact retained package, traceability, regeneration, portability, and Development-only activation evidence. Locator: https://github.com/pinklon/shareplane-platform/pull/256 Description: Public projection names no protected route, account, database identifier, submission, or access roster. [source:shareplane-platform-issue-146] The Code Is No Longer the Hard Part Type: related-work Role: Establishes the cost-inversion predecessor that this article extends into durable governed context. Locator: https://github.com/pinklon/shareplane-platform/issues/146 Description: Related Work, not a duplicate identity or semantic replacement. [source:openai:harness-engineering-2026] Harness engineering: leveraging Codex in an agent-first world Type: first-party-engineering-report Role: External corroboration for repository knowledge as a system of record, context as an engineered resource, and implementation shifting toward agents. Locator: https://openai.com/index/harness-engineering/ Description: Supports parts of the implementation-manufacturability and context-system-design claims without establishing the complete article doctrine. [source:anthropic:context-engineering-2025] Effective context engineering for AI agents Type: first-party-engineering-guidance Role: External corroboration that capable agents depend on deliberately curated context state, tools, history, and external information. Locator: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Description: Supports context-system-design value while remaining narrower than governed institutional semantics. [source:anthropic:long-running-agent-harnesses-2025] Effective harnesses for long-running agents Type: first-party-engineering-report Role: External corroboration that long-running workers need durable artifacts and explicit handoffs across context resets. Locator: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents Description: Supports durable external continuity without treating artifacts as automatically true or authoritative. [source:deepmind:alphaevolve-2025] AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms Type: first-party-research-and-engineering-report Role: External corroboration that models can generate candidate programs and iterate against explicit automated evaluators. Locator: https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/ Description: Supports implementation manufacturability and automated evaluation where objectives and evaluators are valid. [source:nist:ssdf-1.1] Secure Software Development Framework Version 1.1 Type: authoritative-government-standard-guidance Role: Established prior art for documented requirements, design decisions, provenance, verification, and secure lifecycle practices. Locator: https://csrc.nist.gov/pubs/sp/800/218/final Description: Supplies a control boundary without endorsing disposable software or eliminating operational risk. [source:nist:nccoe-devsecops-ai-validation] Secure Software Development, Security, and Operations Practices: Introduction Type: authoritative-government-implementation-guidance Role: Established prior art for verifiable processes and human monitoring and validation of AI-generated software. Locator: https://pages.nist.gov/nccoe-devsecops/introduction.html Description: Supports secure lifecycle controls and continuing human authority without proving the disposable-application doctrine. PROVENANCE BOUNDARY The public article retains only approved public-safe manuscript, metadata, relationships, and sanitized case-study facts. It excludes protected Development hostnames, provider and database identifiers, confidential architecture, real submissions, credentials, and access details. READER RELATIONSHIPS Read the cost-inversion predecessor: artifact:the-application-is-disposable-the-context-is-not -> artifact:the-code-is-no-longer-the-hard-part The predecessor explains where the engineering bottleneck moved; this article explains what becomes durable and how governed context can project implementations. COMPLETE PUBLIC SOURCE # 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. ## What was actually produced The result was not a toy form generated from a vague prompt. It was a protected, working application with: - an eleven-step plain-language ontology interview; - contextual guidance and synthetic examples for each question; - browser-local draft persistence using IndexedDB; - refresh and browser-restart recovery; - portable import and export; - a real shared Cloudflare D1 database; - a provider-neutral API contract; - version-based concurrency control; - rejection of stale updates instead of silent overwrites; - preservation of contradictory semantic assertions; - human review and lifecycle states; - no automatic promotion of submitted opinions into organizational truth; - generated validation rules; - generated OpenAPI definitions; - generated database projections; - generated tests; - generated documentation; - traceability from semantic definitions to application behavior; - and an equivalent Azure architecture using Functions, PostgreSQL or Azure SQL, and Entra ID. The first governed context package was frozen as `cbt-context-collector@0.1.0`. The application, API, schema, documentation, tests, and deployment profiles were projections from that package. The human effort was concentrated where it belonged: - defining the problem; - separating concepts others had collapsed; - establishing authority boundaries; - deciding what the application had to prove; - reviewing the result. The agents performed most of the mechanical transformation. That is the part I do not think enterprises have fully absorbed. AI has not merely made conventional software development faster. It has changed what software is worth preserving. ## 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. ## Disposable does not mean careless The phrase “disposable software” can sound like an invitation to produce uncontrolled junk. That is not what I mean. I do not mean: - untested code; - unowned applications; - abandoned databases; - anonymous cloud resources; - undocumented business rules; - insecure prototypes; - unreviewed agent output; - another generation of enterprise application sprawl. Enterprises already know how to produce those without artificial intelligence. Disposable software means the implementation can be replaced because the meaning that produced it has been preserved elsewhere. A disposable application is: - generated from governed context; - traceable to that context; - independently validated; - deployable into an approved environment; - replaceable without reconstructing the domain from memory; - removable without destroying institutional knowledge; - regenerable when requirements or platforms change. The application is disposable because it is not the only place where the organization remembers what it means. That is the distinction. ## This is not vibe coding A prompt that says “build me an architecture form” is not context as code. It is a request. The model will fill the missing space with assumptions. Some of those assumptions may be useful. Others may be plausible nonsense wearing a modern interface. Context as code is different. The context package defines: - which entities exist; - which questions are asked; - why each question matters; - what evidence is required; - who owns a definition; - which lifecycle states are permitted; - how conflicts are represented; - which transitions are valid; - what must never happen automatically; - how the system behaves when information is unknown. From that package, agents can generate the projections. ```text Governed semantics ↓ Contributor guidance ↓ User interface ↓ Validation ↓ API contract ↓ Database representation ↓ Tests ↓ Documentation ↓ Deployment ``` Change the governed context and regenerate the dependent artifacts. For example, suppose the organization decides: > Every authoritative source must have a named review date. That one semantic change can produce coordinated changes to: - the collection form; - client-side validation; - API validation; - the database projection; - automated tests; - reviewer guidance; - documentation; - traceability receipts. That is not code generation as spectacle. It is controlled projection. ## Why not just use SharePoint? You can. You can use SharePoint Lists, Dataverse, Power Apps, Power Automate, Teams, Confluence, PostgreSQL, Azure SQL, Cloudflare D1, or a conventional custom application. Those are implementation decisions. The mistake is allowing the implementation platform to become the semantic model. A Power App may be an appropriate projection. A SharePoint List may be an appropriate shared store. Confluence may remain the authoritative source for a specific standard. Teams may remain the collaboration surface. Dataverse may provide the approved enterprise persistence layer. None of those choices should require the organization to redefine the meaning of the exercise. The context should be capable of generating or informing each implementation. ```text One governed context ├── SharePlane application ├── Power App ├── SharePoint List schema ├── Azure application ├── Cloudflare application ├── PostgreSQL schema ├── Azure SQL schema ├── interview workbook ├── API contract └── agent context package ``` The platform becomes a target. It stops being the only place where the intent is trapped. ## The ceremony has become more expensive than the software Large enterprises have built substantial controls around software delivery for good reasons. They need: - security; - privacy; - compliance; - segregation of duties; - operational support; - lifecycle management; - audit evidence; - cost control; - architectural alignment. The problem is not that these controls exist. The problem is that the implementation path often bundles necessary control with enormous amounts of manual ceremony. A small internal need can require: - intake; - prioritization; - architecture review; - environment selection; - platform approval; - licensing analysis; - data classification; - security assessment; - development; - testing; - deployment; - documentation; - support assignment; - lifecycle registration. By the time the application exists, the original problem may have changed. That model was tolerable when implementation itself was expensive. It becomes irrational when agents can produce most of the working application, tests, schemas, documentation, and infrastructure definitions from governed context faster than the organization can schedule the intake meeting. The answer is not to eliminate governance. The answer is to encode more of 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: - traceable requirements; - named authority; - controlled lifecycle; - versioned definitions; - deterministic validation; - approved deployment targets; - exact evidence; - known limitations; - reproducible generation; - explicit conflicts; - human approval boundaries. 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. ## The database is disposable too The same principle applies below the user interface. The demonstration used Cloudflare D1 as the shared Development database. The logical contract did not depend on D1. The same behaviors could be projected onto: - PostgreSQL; - Azure Database for PostgreSQL; - Azure SQL; - Dataverse; - another approved relational store. The common semantics remained: - create a contribution; - update it against an expected version; - reject stale changes; - submit it for review; - preserve contradictory claims; - record lifecycle; - prevent automatic canonical promotion. The database product did not define the institutional behavior. It implemented it. That means agents can provision a small database when the application needs one, generate its migration, configure its adapter, run its tests, and retire it later. The database is no longer automatically a long-term architectural commitment. It can be part of a bounded projection. This is an uncomfortable idea for organizations that still treat every schema as a minor civilization. ## The real autonomous machine The important product is not the individual application. It is the machinery that can repeatedly produce applications from governed context. That machinery includes: - a semantic registry; - stable identifiers; - context packages; - generators; - deployment profiles; - policy controls; - identity adapters; - database adapters; - validation suites; - evidence receipts; - lifecycle and retirement rules; - a catalog of active projections. Once that exists, a service area can maintain its institutional semantics and generate fit-for-purpose tools when necessary. A security group could generate a control-assessment application. A laboratory service could generate an equipment-intake tool. An architecture group could generate a standards interview. A compliance group could generate an evidence collector. A program team could generate a decision workbench. A migration team could generate a readiness assessment. These do not all need to become permanent products. They need to solve the current problem faithfully, operate within approved boundaries, and leave the durable context better than they found it. ## The sprawl risk is real Cheap software can create an app explosion. If every person can generate a bespoke application, the enterprise can quickly accumulate: - duplicate tools; - abandoned databases; - unclear ownership; - conflicting definitions; - unmanaged costs; - stale security dependencies; - invisible data stores; - applications nobody remembers creating. The old delivery model controlled sprawl partly by making software painful to produce. Pain is a crude governance mechanism, but apparently it has enjoyed a long career in enterprise architecture. When production becomes cheap, governance must become explicit. Every generated application should have: - an owner; - a context source; - an approved data classification; - a deployment profile; - a lifecycle state; - an expiration or review date; - a cost boundary; - a visibility classification; - a deletion path; - evidence tying it to its generating context. Disposable software requires a factory. It also requires a graveyard. The answer to application sprawl is not to preserve expensive manual development. It is to govern generation, operation, and retirement. ## 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: ### Durable platforms Long-lived systems that justify substantial investment, operational support, and formal product management. ### Durable context Institutional semantics, rules, evidence requirements, and contracts that must survive platform changes. ### Regenerable applications Purpose-built projections that can be replaced, revised, or retired without losing the meaning that produced them. ### Temporary instruments Short-lived tools generated for a bounded decision, migration, assessment, investigation, or collection exercise. Not everything needs to become a product. Sometimes the professional answer is to build something excellent, use it, preserve what was learned, and delete the implementation. ## The shift The old model was: > Build the application and document what it means. The emerging model is: > Define what the organization means and generate the application. That inversion changes: - architecture; - funding; - governance; - ownership; - platform strategy; - software lifecycle; - developer roles; - service management. The durable expertise moves upward. People define the domain, authority, evidence, risk, and acceptable outcomes. Agents translate that into software. Infrastructure becomes a selectable projection. Applications become cheaper to create and easier to replace. The organization preserves meaning instead of preserving every implementation that once contained it. ## 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. > **Preserve the meaning. Generate the software. Retire the projection when its job is done.**