CodeAnvil Model Charter

Version: 1.0

Status: active foundation model

Date: 2026-07-21

System Thesis

CodeAnvil 将声明转化为受治理的运行状态。X-CodeAnvil 将未知可能性转化为受治理的 X。

CodeAnvil turns declarations into governed runtime state. X-CodeAnvil turns unknown possibilities into governed X.

Canonical Judgment

CodeAnvil, CodeAnvil Kernel, CKIMS, and X-CodeAnvil are not four peer products.

The stable model is:

1. CodeAnvil is the programmable infrastructure and execution system.

2. CodeAnvil Kernel is the deterministic execution kernel inside CodeAnvil.

3. CKIMS is the Human + Agent control plane for operating CodeAnvil.

4. X-CodeAnvil is the external X forge and operation system built on top of CodeAnvil.

5. In CKIMS, created systems are called `instances`; in world narrative and brand language, the created thing is called `X`.

Layer Order

Human / Codex / External Systems / Unknown Intent
        |
        v
X-CodeAnvil
        |
        v
CodeAnvil
        |
        +-- CKIMS
        +-- Platform Services
        +-- State, Event, Policy, Artifact, Release, Domain Ledgers
        |
        v
CodeAnvil Kernel
        |
        v
Cloudflare Application Ecosystem

Non-Negotiable Invariants

1. CodeAnvil can run without X-CodeAnvil.

2. X-CodeAnvil obtains digital runtime capability through CodeAnvil.

3. CodeAnvil Kernel is an internal deterministic kernel, not the public product name.

4. CKIMS is a control plane, not a public entity interface.

5. X-CodeAnvil must not bypass CodeAnvil to mutate Cloudflare resources.

6. Kernel must not own X business meaning, value judgment, or governance semantics.

7. Every state change has principal, plan, authorization, execution, verification, and evidence.

8. Cloudflare is the current runtime substrate, not the domain identity of CodeAnvil.

9. Codex is the current primary Agent Operator, not the only possible agent.

10. Conversation is never the final source of truth; it is compiled into model, plan, decision, ledger, or evidence.

11. CKIMS object vocabulary uses `instance`; public/world vocabulary uses `X`.

12. `x-codeanvil.io` is the X-CodeAnvil brand IO and must be governed as a CodeAnvil foundation domain asset.

Source Of Truth

The CodeAnvil Model document system is the upper document authority. CKIMS and Kernel ledgers are the runtime authority. Local Work files are temporary intake material only.

Naming And Terminology

Official Names

Boundary Rules

Required Object Vocabulary

Forbidden Naming Patterns

System Architecture

CodeAnvil

CodeAnvil accepts declarations, policies, artifacts, approvals, and operating commands. It returns governed runtime state, deployment evidence, resource state, audit history, and reconciliation signals.

Core planes:

CodeAnvil Kernel

Kernel standard loop:

Declare -> Validate -> Diff -> Plan -> Authorize -> Apply
   ^                                               |
   |                                               v
Reconcile <- Observe <- Record <- Verify <---------

Kernel is deliberately narrow. It receives authorized state changes, produces plans, applies provider operations through controlled drivers, verifies results, records evidence, and reconciles drift.

CKIMS

CKIMS exposes the same governed fact surface to Human and Agent operators:

CKIMS does not replace Cloudflare Dashboard. It defines which provider actions are allowed, why they are allowed, who approved them, what evidence exists, and how any future operator continues.

X-CodeAnvil

X-CodeAnvil turns unknown inputs into X Manifest and governed X:

Unknown -> Candidate X -> Specified X -> Forgeable X -> Commissioned X -> Operational X -> Evolved X

The digital runtime portion of X is compiled into CodeAnvil deployment specifications and becomes a CKIMS `instance` when approved. X meaning, business logic, governance, metrics, and evolution remain in X-CodeAnvil.

Contract Between X-CodeAnvil And CodeAnvil

Cloudflare Provider Model

Cloudflare is the current CodeAnvil runtime substrate. CodeAnvil should be Cloudflare-native first, while keeping its domain model independent from Cloudflare product names.

Provider Planes

Current CKIMS Interpretation

Binding Rule

When running inside Workers or Pages Functions, Cloudflare bindings are preferred over REST API calls for bound resources. REST API access remains a provider administration path used by local owner-deploy scripts and must be governed by provider contracts and LocalOnly secrets.

Provider Execution Policy

Provider-side create, change, delete, or route mutation requires:

1. Resource plan.

2. Owner approval.

3. Active provider execution policy.

4. Active runbook.

5. Rollback or compensation evidence.

6. Deployment ledger record.

7. Route smoke and inventory audit.

8. Audit log.

Security, Governance, And Audit

Principal Model

Human, Codex, autonomous agents, services, and X entities are principals. They operate through scoped workseats or service contracts.

Core Rules

Risk Scale

Evidence Chain

Intent
  -> Plan
  -> Approval
  -> Provider Execution Policy
  -> Runbook
  -> Deployment / Change Record
  -> Verification
  -> Audit
  -> Continuation State

Identity Mapping

Cloudflare Access identity must be mapped into CKIMS workseats through `identity_mappings`. Owner capability is never inferred from email alone unless the mapping is active and audited.

Break-Glass

Emergency access must include:

Implementation Roadmap

Phase 0: Constitution

Deliver:

Exit condition: any Codex entering CodeAnvil can read the model, understand the hierarchy, and continue without guessing.

Phase 1: CodeAnvil Spine

Deliver:

Exit condition: a governed Cloudflare surface can be planned, approved, deployed, verified, audited, and rolled back.

Phase 2: Governed Operations

Deliver:

Exit condition: routine operations no longer depend on ad hoc Codex reasoning.

Phase 3: X Forge

Deliver:

Exit condition: X-CodeAnvil can define an X and ask CodeAnvil to produce its governed runtime.

Phase 4: X Operations

Deliver:

Exit condition: X operational meaning and CodeAnvil infrastructure facts are connected but not confused.

Phase 5: Evolution And Portfolio

Deliver:

Exit condition: multiple X entities can evolve while preserving model, evidence, and audit.

Domain And Surface Registry

Brand Domain

`x-codeanvil.io` is the planned X-CodeAnvil brand IO and the governed parent domain for public or semi-public CodeAnvil model surfaces.

This domain is a CodeAnvil foundation asset. Its subdomains are created through CKIMS resource plans and domain records, not ad hoc dashboard edits.

Planned Subdomains

X / Instance Rule

Public language uses X. CKIMS system language uses `instance`.

An X becomes operational only when CKIMS has an instance request, resource plan, security profile, allocation records, deployment evidence, and audit trail. Domains and subdomains are assigned by CKIMS to infrastructure or instances; no X receives ad hoc DNS or storage.

Actual Domain Rule

Actual domain count comes from CKIMS foundation assets with `asset_type=domain` only.

DNS records, Pages URLs, Worker default domains, Access application domains, aliases, routes, and deployment URLs are child records/evidence.

Creation Rule

No subdomain becomes official until it has:

1. Domain asset or parent domain record.

2. Resource plan.

3. Surface record.

4. Owner approval when public or production.

5. Deployment or route record.

6. Audit entry.