A governed micro-application platform

Every app declares what it is. The platform holds it to that.

Charter replaces large monolithic IT delivery with small, AI-generated, purpose-built applications. Each one declares its charter: what it is, what it owns, where its data lives, what review it carries. Conformance is checked by machine, at authoring time, before a line of code ships.

charter.yaml validated at authoring time
app: trade-mirror-worker
template: worker
ownership: consume
capabilities:
  [config, observability,
   resilience, cache, lifecycle]
provenance:
  generated: true
  pipeline: charter new
  reviewTier: standard
# chartered is machine-checkable

The problem

Monoliths are slow. Ungoverned AI generation is sprawl.

Public-sector IT programs put every new requirement into a monolith's backlog or a bespoke project that reinvents auth, logging, deployment, and security review from scratch. AI code generation makes producing apps cheap, but cheap production without governance produces unmaintainable sprawl. The gap is a platform that makes generated apps conformant, observable, and accounted for by construction.

Without Charter

Every app is a snowflake. Identity, telemetry, and secrets handled differently each time. Review happens after the fact, by reading code. Nobody can say with confidence what a generated app owns, where its data lives, or which model produced it.

With Charter

Apps conform to one scaffold and inherit shared capabilities instead of reimplementing them. Each app carries a declared charter, validated against the same schema the runtime enforces. Existing ERPs and CRMs are never modified: apps run alongside them, non-invasive by construction.

The platform

Eight capabilities available to every chartered app, declared per app, wired by the platform.

Providers are configuration: the same app runs against Entra ID or any OIDC provider, Application Insights or any OpenTelemetry backend, without a code change.

identity

Identity

OIDC as the open standard. Auth middleware and token handling from the platform, provider chosen by config.

observability

Observability

OpenTelemetry built in at boot. Every app is traceable and operable from day one, or it is not chartered.

config

Configuration

Loaded once through the platform layer, including secrets via a pluggable vault abstraction.

resilience

Resilience

Timeouts on every outbound call, bounded retries, declared behavior on dependency failure.

cache

Caching

In-memory, Redis, or off, selected by config. App code never knows which backend is live.

feature-flags

Feature flags

Role and tenant targeting, per-ministry rollouts, percentage releases, cloud-neutral.

data-access

Data access

Governed Postgres persistence with write-deduplication and idempotency, for apps that own data.

lifecycle

Lifecycle

App metadata, versioning, and lifecycle governance carried in the charter itself.

How it works

From a written spec to a chartered app, with a birth certificate.

Generation runs through charter new, a staged pipeline with gates between stages. An app that skips the pipeline has no provenance, and an app without provenance fails conformance. The pipeline is model-agnostic: the generating model sits behind a swappable provider interface, like every other provider in the platform.

1

Write the spec

A plain-language solution spec: what the app does, its sources, cadence, outputs, and how it behaves when things fail. The spec is plain language. The translation stage proposes a charter with a rationale per field, and a person concludes ownership and classification, with the answer and the respondent recorded.

2

Run the pipeline

charter new assembles each stage's prompt from the spec, the live schema, and the platform templates, generates through the model provider, and gates every stage. Nothing advances past a failed gate.

3

Validate by machine

The app's charter is validated against the same schema the runtime enforces. charter check runs independently after the pipeline: conformance is verified, not claimed. Owned-data apps route automatically to heightened review.

Governance

Two tiers. One is the default, the other is earned.

Non-invasiveness to existing systems is absolute in both tiers. What varies is not whether apps can write, both tiers can, but who holds authority over the data. Ownership is never a silent default: it is declared, bounded, and machine-checked.

Standard tier · default

Consuming apps

Not read-only. Consuming apps submit requests, trigger workflows, and update records, always through existing systems' sanctioned interfaces. What they never do is become the official record: source systems stay authoritative, and the app holds no durable state beyond caches and operational artifacts. Most apps belong here.

Governed tier · heightened review

Owning apps

The app owns a Postgres database and becomes the system of record for a bounded domain. Legitimate, and deliberately expensive. It cannot pass validation without declaring:

  • Its system-of-record boundary, stated precisely
  • Its data residency: sovereign cloud, on-prem, or air-gapped
  • Heightened review, routed automatically by the schema

Deployment

Sovereign by default. A kubeconfig is enough.

Charter is cloud-agnostic and built on open standards: OIDC for identity, OpenTelemetry for observability, OpenTofu for infrastructure. The portable path targets any conformant Kubernetes cluster, including sovereign cloud, on-prem, and air-gapped environments, with no cloud-provider dependency in the plan. The same app moves between environments by configuration alone. Certification currently has one public-registry dependency, the audit gate's advisory lookup, logged as a finding; offline certification is not yet claimed.

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 provider implementations are deferred and incremental behind the same interface.

$ charter new specs/trade-mirror.md
stage 1/4 · charter drafted ······ pass
stage 2/4 · generation ··········· pass
stage 3/4 · charter check ········ pass
stage 4/4 · provenance stamped ··· pass

$ tofu apply -var-file=sovereign.tfvars
cluster: on-prem · kubeconfig only
apply complete

Status · September 2026

What is real today, and what is next.

Shipped

  • Platform foundation, cloud-agnosticProven by the reference app booting with zero cloud services
  • All eight shared capabilitiesIncluding governed data access, caching, and feature flags
  • Generation pipeline, charter newStaged, gated, with authoring-time validation against the runtime schema
  • Provenance and prompt captureExact prompts, model identity, and schema version per generated app
  • Spec-to-charter translationPlain-language specs proposed into charters by the pipeline, so authors need requirement language, not platform vocabulary
  • First pilot: CERTGenerated end to end, fully local, with a live Platform Panel
  • Second pilot: Trade Mirror ReportGenerated end to end through the harness; generation 1 stamped 2026-07-04 at 89.09% gate coverage
  • Second pilot: regeneration lineageDemonstrated on trade-mirror at generation 2: regenerated 2026-09-12 from a human-concluded re-translation, chain verified to generation 1 by charter check, stamped at 90.88% gate coverage
  • Second pilot: adapter-level live verificationA national open data portal live-verified at adapter level on 2026-07-08, on the generation-1 adapter built outside the harness; an international trade statistics database probed to authentication refusal. Not repeated on generation 2, whose adapters are fixture-tested only
  • Capability-config validationDeclared capability config validated against pinned schemas at every generation gate and in charter check; charters declare configuration, never credentials
  • Organizational accountability: declared in every charterEvery charter names an accountable unit; the contract requires it on every app
  • Organizational accountability: owner registryThe accountable unit is resolved against a versioned owner registry at authoring time and at certification; an unregistered or placeholder owner fails by name
  • Data classification: tier routingRestricted or confidential routes the app to heightened review exactly as owned data does, and never lowers a tier
  • Data classification: concluded by a personClassification is concluded by a person, never defaulted
  • Review-by enforcementEvery charter carries a re-review date proposed from its tier and confirmed by a person; a date in the past fails certification by name, REVIEW_BY_EXPIRED, not a warning
  • Integrations declared per appExternal systems declared per app with hosts, credentials by reference, and cadence; a static gate fails an undeclared outbound host by name and warns by name on declared-but-unwired or statically unresolvable targets. Static detection only: runtime egress verification is not built
  • Declared-versus-wired capability conformanceEvery declared capability must be wired and every wired capability declared, checked statically in both directions at certification, with the pilot-two identity finding as its permanent test fixture. Static detection; runtime truth is not claimed
  • Cloud-neutral deployment hardeningMulti-environment OpenTofu, secret rotation without redeploy, per-environment trace sampling, alert rules as code, and a deploy path with rollback exercised on a local cluster

In progress

  • External stakeholder pilotA real client problem with connected systems, the platform's proving ground
  • Second pilot: live operationAdapter-level live verification on the generation-2 code, and end-to-end scheduled operation, neither yet demonstrated; the only scheduled runs on record failed and the rendered demo was fixture-fed