Module 2: VCP architecture

2.1 — The bundle: VCP's core unit

A bundle is the signed package a constitutional document travels in. It contains:

• Content: The constitutional text itself (principles, rules, guidance)
• Manifest: The bundle's metadata. It records who authored the bundle, when, which version it is, and when it expires. It also holds a content hash (a fingerprint of the content, which changes if a single character does) and a token budget (how many of the model's text units, called tokens, the content will use; these are unrelated to the CSM-1 token mentioned below).
• Signatures: Cryptographic proof that the bundle has not changed since its issuer, the organization that published it, signed it. The bundle also carries an attestation, a second signature from an auditor recording that the auditor reviewed it. A verifier accepts these signatures only from issuers and auditors on its own list of trusted keys, called trust anchors.

Once published, a bundle should never be changed. To update it, issue a new version and revoke or retire the old one through your governance process.

Here is an example manifest, adapted from the VCP specification's schema examples. It shows the manifest only; the constitutional text is referred to by its content_hash. The hash and signatures are placeholders, and the signatures are too short to pass the schema, so treat this as a picture of the structure rather than a bundle that would verify.

{
  "vcp_version": "1.0",
  "bundle": {
    "id": "creed://example.org/support/guide",
    "version": "1.0.0",
    "content_hash": "sha256:0000000000000000000000000000000000000000000000000000000000000000"
  },
  "issuer": {
    "id": "example.org",
    "public_key": "ed25519:AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=",
    "key_id": "example-2026"
  },
  "timestamps": {
    "iat": "2026-01-01T00:00:00Z",
    "nbf": "2026-01-01T00:00:00Z",
    "exp": "2026-03-31T00:00:00Z",
    "jti": "123e4567-e89b-42d3-a456-426614174000"
  },
  "budget": {
    "token_count": 128,
    "tokenizer": "cl100k_base"
  },
  "safety_attestation": {
    "auditor": "review.example.org",
    "auditor_key_id": "review-2026",
    "reviewed_at": "2026-01-01T00:00:00Z",
    "attestation_type": "injection-safe",
    "signature": "base64:YQ=="
  },
  "signature": {
    "algorithm": "ed25519",
    "value": "base64:YQ==",
    "signed_fields": [
      "vcp_version", "bundle", "issuer", "timestamps",
      "budget", "safety_attestation"
    ]
  }
}

2.2 — CSM-1 codes: the Constitutional Safety Minicode

DEV CSM-1, the Constitutional Safety Minicode, is VCP's one-line summary of a constitutional configuration: persona, adherence level, and scopes, with an optional namespace and version. A CSM-1 code works like a film's age rating, which tells you what to expect without showing you the film. Many constitutions can share one code; the bundle's content hash is what identifies a specific constitution. (CSM-1 also defines a longer, multi-line token that carries constitutional and personal state together. This section covers the one-line code.)

Format: {persona}{level}[+scopes][:namespace][@version]

Personas define the constitutional archetype:

Adherence level (0–5): how strictly the constitution is enforced and how strongly the persona acts, from 0 Minimal (advisory only, never blocks) through 1 Relaxed, 2 Moderate, 3 Standard, and 4 Strict to 5 Maximum (no exceptions).

Scopes say which settings the constitution covers (a code with no scopes applies in all settings):

Adult (A) cannot be combined with Family, Vulnerable, or Health.

Examples:

• N5+F+E — Nanny at level 5 (Maximum), covering family and education
• Z3+P:SEC — Sentinel at level 3, privacy scope, security namespace
• G4@1.0.0 — Godparent at level 4, version 1.0.0
• M2+E+W — Muse at level 2 (Moderate), education and work scopes

CSM-1 codes enable quick matching: "Does this service support the kind of constitution I want to use?" without transmitting the full constitutional text.

Try it yourself: The VCP Inspector lets you decode and encode CSM-1 codes (NANO, MICRO, or COMPACT tier) interactively. Paste a code into the Decode tab to see its field-by-field breakdown, or use the Encode tab to build one with live preview.

2.3 — Verification: trust without faith

When an application receives a VCP bundle, it doesn't just trust it. Before any of the content reaches the model, the verification pipeline checks, in this order:

1. Size limits — Are the manifest and content within acceptable bounds?
2. Schema validity — Does the manifest have all required fields?
3. Content integrity — Does the content match its hash?
4. Issuer trust — Is this signed by a trusted issuer?
5. Signature validity — Does the cryptographic signature verify?
6. Auditor trust — Is the attestation from a trusted auditor?
7. Attestation validity — Does the auditor's signature verify?
8. Revocation status — Has this bundle been revoked?
9. Temporal validity — Is the bundle within its valid time window?
10. Replay protection — Has this bundle's unique issue ID (the jti field) been seen before?
11. Budget compliance — Does the content fit within the model's context budget?
12. Scope matching — Is the bundle issued for this model, purpose, and environment? (This deployment scope is separate from the CSM-1 scopes above.)
13. Content safety scan — Is the content free of the prompt-injection patterns the SDK scans for?

Verification stops at the first check that fails. VCP-SDK 4.2.0 returns one of 18 verification outcomes, grouped here by the SDK's category (Python and Rust use the same categories):

GOVERNANCE A successful verification is evidence of which bundle one system accepted at the moment it received it. Proving which values shaped a whole conversation takes more: the application's own logs, a record of which deployment and model handled each call, controls on how long those records are kept, and a review of what the system actually did.

2.4 — The value lifecycle

End-to-end flow:

Author constitution → Sign bundle → Publish →
   Application fetches → Verifies → Injects into the model's context →
      AI responds guided by values →
         Application audit log can record which bundle was verified

After publication, the issuer can revoke a bundle, and verifiers that check its revocation status will then reject it. The auditor's attestation is signed into the bundle when it is built, so a new or different review means issuing a new version. Context adaptation, covered in Module 5, changes how the values apply to the situation at hand when the bundle is used, without changing the bundle.

Before exchanging bundles, two systems can agree on which VCP features they both support, a step called capability negotiation. One side sends a VCP-Hello message listing what it can do, and the other replies with a VCP-Ack. The Capability tab of the VCP Inspector lets you try the exchange.

VCP defines how to check a signed bundle, but it cannot make an application do the checking. The application must verify each bundle before acting on it, and keep enough records to show where the bundle was used.