A governed micro-application platform

AI has made code cheap to produce. It has not made software cheaper to own.

The people accountable for an application still answer for what it does, what data it holds and how it was built, often without having written any of it.

How an app is made The open contract

How an app is made

From a requirement to a recorded app.

The model that writes the code is called through a provider interface. One provider is implemented.

1

The requirement

Someone writes what the app should do, in plain language. The requirement needs no platform vocabulary.

2

The charter, confirmed by a person

The platform proposes a charter from the requirement and asks a person the questions that are theirs to answer: what data the app owns, where it lives, how sensitive it is, who is accountable for it. The person's answers are recorded. No code is generated before the person confirms the charter.

3

Generation in checked stages

The app is generated in stages. After each stage, fixed rules check the charter and the code against the schema and against each other. A stage that fails stops the run.

4

The recorded run

The run is recorded with the prompts sent to the model, the model used and the schema version. The app's charter points to that record.

5

Regeneration

When the requirement changes, the app is generated again through the same stages. The new record points to the previous one. This has been demonstrated once; the Status section gives its limits.

What a charter declares

A charter is a file kept with the app's code.

This example is for an invented app that handles permit renewals. It consumes data from an existing registry and owns none. Its classification is internal, so it routes to standard review. The example is valid against the v0.3.0 schema.

Every field is defined in the charter field reference.

charter.yaml example · schema v0.3.0
name: permit-renewals
owner: licensing-team
accountability:
  owner: licensing-office
  reviewBy: 2027-04-01
domainBoundary: "Renewal requests for existing business permits"
runtimePattern: api
dependencies: []
dataPattern:
  storage: none
  ownership: consume
  classification: internal
  retention: 1y
  auditRequired: true
lifecycle: active
aiGenerated: true
aiTools: [claude-code]
capabilities:
  identity: {}
  config: {}
  observability: {}
  resilience: {}
  cache:
    backend: memory
    keyPrefix: "renewals:"
integrations:
  - name: permit-registry
    hostsFrom: PERMIT_REGISTRY_URL
    credentials: [permit-registry-key]
    cadence: on-demand
    mode: live
# provenance is added by the harness when the app is generated

Governance

Two governance tiers.

Apps in both tiers leave existing systems unchanged and reach them only through their sanctioned interfaces. Apps in both tiers can write. The tiers differ in who holds authority over the data.

Standard tier · default

Consuming apps

A consuming app submits requests, triggers workflows and updates records through the systems that own them. It holds no durable state beyond caches and operational artifacts. The source systems stay authoritative. Most apps belong here.

Heightened review

Owning apps, and sensitive data

An app that owns its data is the system of record for a bounded domain. Its charter must declare:

  • What it is the system of record for
  • Where the data lives

An owning app routes to heightened review. So does any app whose data is classified restricted or confidential. The schema derives the tier from these answers; nobody sets it by hand.

The platform

Eight shared capabilities.

Every app inherits these from the platform and declares them in its charter. Identity and telemetry are built on open standards, OIDC and OpenTelemetry, and the provider is configuration. The providers run so far are a local OIDC issuer and the OpenTelemetry Collector, on the local stack and a local Kubernetes cluster. Other providers are not yet demonstrated.

identity

Identity

OIDC token validation and role checks.

observability

Observability

Structured logs, correlation IDs and OpenTelemetry export from startup.

config

Configuration

Configuration and secrets read through one interface.

resilience

Resilience

An HTTP client with timeouts, bounded retries and a circuit breaker.

cache

Caching

In-memory, Redis or none, as the charter declares.

feature-flags

Feature flags

Flags targeted by role, tenant or percentage.

data-access

Data access

Owned storage, in memory or on Postgres, with idempotent writes.

lifecycle

Lifecycle

The charter validated at startup, and lifecycle telemetry.

Deployment

Kubernetes with OpenTofu.

The deployment path is OpenTofu on a Kubernetes cluster, configured through a kubeconfig, with no cloud provider in the plan. Three environments are built from one module. Deployment, a smoke test, a forced failure and a rollback have been exercised on a local cluster. The path has not yet run on a managed or sovereign cluster.

Checking an app's conformance still depends on one public registry, the advisory lookup in the audit check. That dependency is a defect to be removed, and it is disclosed here until it is.

An optional Azure-native path (Bicep, Container Apps) exists as a convenience for teams already committed to Azure. It is not part of the portability claim. AWS and GCP are not implemented.

The open contract

What is published.

The charter format is open. Its schema, the principles behind it and the conformance codes are published under Apache 2.0, and anyone can use or implement them.

It is published in the charter-spec repository and contains:

Status · October 2026

What is real today, and what is next.

Each claim below is checked against its evidence before the page is published. Each states what is not yet shown.

Shipped

  • The open contract publishedThe charter schema and validator, the principles, claim strength, the conformance codes, a glossary and a field reference, under Apache 2.0. No test yet compares the field reference with the schema.
  • The governed runtimeEight shared capabilities every app inherits, on open standards, running with no cloud services. Only a local OIDC issuer and the OpenTelemetry Collector have been run as providers.
  • Governed generationA person confirms the charter before code is generated, each stage is checked against it by fixed rules, and the run is recorded with its prompts and model. Regeneration with a record that carries forward has been demonstrated once. It holds for apps whose confirmed charter was kept in the repository; other apps cannot yet be regenerated with a matching record.
  • Governance declarations checked by machineOwnership, classification, accountability, a review date, external systems and inherited capabilities are declared in every charter and checked against the schema, an owner registry and the code, statically. The checks do not yet confirm that each declared answer is the one a person gave.
  • Portable deployment exercised on a local clusterOpenTofu on Kubernetes, with deployment, a smoke test, a forced failure and a rollback exercised on a local cluster. Not yet run on a managed or sovereign cluster.

Next

  • Chartered status checked end to endThe platform's check reports whether an app is chartered, and the checks confirm that each declared answer is the one a person gave.