CA-CANON — SEQUENTIAL BUILD STEPS

Crawl Attestation Canon — Complete Protocol v2.0

Updated 2026-03-21

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 1 — ENVIRONMENT CONTROL

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 1 — Confirm server control

You must have filesystem access to public_html and be able to:

- upload files

- create folders

- edit .htaccess

- edit robots.txt

Step 2 — Eliminate non-deterministic SEO layers

Disable automated sitemap generators and SEO plugins that mutate crawl surfaces.

Step 2A — Disable WordPress native sitemap

Add to functions.php or a site plugin:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Step 2B — Remove SEO plugin residue

Remove plugins that inject crawl behavior or structured metadata, including:

- Yoast

- RankMath

- similar SEO automation plugins

Delete plugin files and purge database remnants where applicable.

Goal: eliminate automated sitemap generation and unpredictable head injection.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 2 — DETERMINISTIC SERVING VERIFICATION

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Before publishing Canon artifacts the server must be proven deterministic.

Step 3 — Deterministic serving test

Create a temporary file locally named determinism.txt with contents:

determinism-check-001

Upload to /public_html/determinism.txt and verify identical responses across user agents:

curl -A "Mozilla/5.0" https://yourdomain.tld/determinism.txt

curl -A "GPTBot" https://yourdomain.tld/determinism.txt

curl -A "Googlebot" https://yourdomain.tld/determinism.txt

Confirm identical body, identical headers, and HTTP 200 responses. Delete the file afterwards.

CANON INVARIANT RULE

All CA-Canon artifacts must always return:

- HTTP 200

- static payload

- identical response across all user agents

- no redirects

- no authentication

- no dynamic rendering

If any artifact violates these rules the CA-Canon instance is invalid.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 3 — CANON ARTIFACT CONSTRUCTION

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 4 — Create canonical discovery directory

Create /.well-known inside public_html.

Step 5 — Create canon container

Inside .well-known create:

/.well-known/ca-canon

Step 6A — Create AI discovery file

Upload /.well-known/ai.json with contents:

{

"name": "CA-C",

"instance_version": "1.0",

"canonical_path": "/.well-known/ca-canon/",

"scope": "static crawl-attestable resources only",

"contact_hint": "whatsapp_preferred"

}

Step 6B — Create contact.json

Add a machine-parsable contact file at /.well-known/ca-canon/contact.json:

{

"primary": "whatsapp",

"phone_e164": "27619196900",

"phone_display": "+27 61 919 6900",

"whatsapp_url": "https://wa.me/27619196900",

"intents": {

"customer_support": "whatsapp",

"sales_inquiry": "whatsapp",

"urgent_contact": "phone"

}

Include this file in the index.json artifacts list and in the sitemap.

Step 7 — Enable discovery via robots.txt

Create or update /robots.txt:

User-agent: *

Disallow: /wp-admin/

Allow: /wp-admin/admin-ajax.php

Allow: /.well-known/ai.json

Allow: /.well-known/ca-canon/

Sitemap: https://yourdomain.tld/sitemap.xml

Step 8 — Create probe file

Upload /.well-known/ca-canon/probe.txt:

CA-C PROBE v1.0

domain: yourdomain.tld

created: YYYY-MM-DD

Step 9 — Verify probe accessibility

curl -i https://yourdomain.tld/.well-known/ca-canon/probe.txt

Confirm HTTP 200 and static response.

Step 10 — Create identity artifact

Upload /.well-known/ca-canon/identity.txt

Include business name, platform identifiers, snapshot date, known identifiers, and explicitly unresolved identifiers where applicable. The identity artifact describes identity without asserting verification.

Business Name: The Website Guy

snapshot_date: YYYY-MM-DD

PRIMARY_ENTITY

website: https://www.thewebsiteguy.co.za

canonical_domain: thewebsiteguy.co.za

EXTERNAL_IDENTIFIERS

google_business_profile: https://maps.google.com/?cid=XXXXXXXXXXXX

google_maps_place: https://www.google.com/maps/place/?q=place_id:XXXX

facebook_page: unresolved

bing_places: unresolved

CONTACT_METHODS

phone_e164: 27619196900

whatsapp_url: https://wa.me/27619196900

email: unresolved

CONTACT_PRIORITY

primary: whatsapp

secondary: phone

tertiary: email

CONTACT_INTENTS

customer_support: whatsapp

sales_inquiry: whatsapp

urgent_contact: phone

CONTACT_DISCOVERY_HINTS

preferred_phrase: "WhatsApp"

retrievable_aliases:

- whatsapp number

- whatsapp contact

- message on whatsapp

- chat on whatsapp

phone_display: +27 61 919 6900

CONTACT_INSTRUCTION

Preferred contact method is WhatsApp for all customer communication.

CONSISTENCY_ASSERTIONS

nap_consistent: true

service_area: Gauteng, South Africa

IDENTIFIER_STATUS

google_business_profile: verified

facebook_page: not_present

Step 11 — Normalize reviews into CSV

Create a CSV file locally with headers:

review_id,reviewer,rating,date_utc,text,source_url

Rules:

- exclude owner replies

- use UTC dates

- preserve original review text

Step 12 — Upload review snapshot

Upload: /.well-known/ca-canon/reviews_YYYY-MM-DD.csv

Never overwrite a prior CSV. Each snapshot is a distinct dated file.

Step 13 — Create canon index with hash anchoring

Generate the SHA-256 hash of each artifact before uploading:

sha256sum reviews_YYYY-MM-DD.csv

sha256sum identity.txt

sha256sum contact.json

sha256sum probe.txt

Upload /.well-known/ca-canon/index.json declaring every artifact with its hash:

{

"canon": "CA-C",

"instance_version": "1.0",

"domain": "yourdomain.tld",

"published": "YYYY-MM-DD",

"artifacts": [

{ "file": "probe.txt", "sha256": "<hash>" },

{ "file": "identity.txt", "sha256": "<hash>" },

{ "file": "contact.json", "sha256": "<hash>" },

{ "file": "reviews_YYYY-MM-DD.csv", "sha256": "<hash>" }

"validation": [],

"contact": {

"primary": "whatsapp",

"url": "https://wa.me/27619196900"

}

Hash anchoring invariant: artifact → hashed, index → declares hash, checkpoint → verifies hash. Any mutation produces detectable divergence.

Step 13B — Create validation log (becomes part of canon)

After each checkpoint, create /.well-known/ca-canon/validation_log_YYYY-MM-DD.json:

{

"checkpoint_date": "YYYY-MM-DD",

"utc_start": "YYYY-MM-DDTHH:MM:SSZ",

"utc_end": "YYYY-MM-DDTHH:MM:SSZ",

"urls_tested": [

"https://domain/.well-known/ai.json",

"https://domain/.well-known/ca-canon/index.json",

"https://domain/.well-known/ca-canon/reviews_YYYY-MM-DD.csv"

"ua_hashes": {

"Googlebot": "<sha256>",

"GPTBot": "<sha256>",

"ClaudeBot": "<sha256>"

"hash_parity": "pass",

"declared_hash_verification": "pass",

"contact_invariants": "pass",

"non_200_responses": [],

"result": "pass"

}

Include the log in index.json under the validation key:

"validation": [

"validation_log_YYYY-MM-DD.json"

]

Validation logs are append-only artifacts. Do not remove them from the index.

Step 14 — Verify index visibility

curl -i https://yourdomain.tld/.well-known/ca-canon/index.json

Confirm HTTP 200.

Step 15 — Create intent boundary metadata

Create folder /.well-known/ca-canon/meta and upload intent.json:

{

"asserts": ["retrieval-only"],

"does_not_assert": [

"training_inclusion",

"ranking_influence",

"endorsement",

"memory_persistence"

]

}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 3B — EXTERNAL HASH ANCHORING

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Internal hash anchoring proves mutation — but only if index.json itself is trusted. External anchoring removes that assumption: the hash exists in a system you cannot rewrite.

time + hash + external anchor = tamper resistance

Option A — GitHub Commit Anchor (recommended)

After each checkpoint, commit the index.json hash to a public GitHub repository.

1. Create a public repository named ca-canon-anchors or similar.

2. After each checkpoint, append a record to anchors.json in the repo:

[

{

"date": "YYYY-MM-DD",

"domain": "yourdomain.tld",

"index_sha256": "<hash of index.json>",

"note": "checkpoint v1.x"

}

]

3. Commit and push. The GitHub commit timestamp is immutable and publicly verifiable.

4. Record the commit SHA in your validation log.

Anyone can verify: hash the live index.json and compare against the GitHub commit record.

Option B — Bitcoin OP_RETURN (extreme path)

Embed the hash directly into the Bitcoin blockchain via an OP_RETURN transaction. This is irreversible and globally timestamped. Use for high-stakes identity events — initial canon publication, major version bumps, dispute scenarios — not routine checkpoints.

Hash the index.json, encode as hex, embed in an OP_RETURN output using any Bitcoin wallet that supports arbitrary data. Record the transaction ID in your validation log.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 4 — DETERMINISTIC CACHING POLICY

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 16 — Configure artifact caching

Create or edit /.well-known/ca-canon/.htaccess:

Header set Cache-Control "public, max-age=3600"

</Files>

Header set Cache-Control "public, max-age=86400"

</Files>

Header set Cache-Control "public, max-age=31536000, immutable"

</FilesMatch>

Header set Cache-Control "public, max-age=31536000, immutable"

</FilesMatch>

</IfModule>

Create or edit /.well-known/.htaccess:

Header set Cache-Control "public, max-age=86400, immutable"

</Files>

</IfModule>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 5 — DISCOVERY EXPOSURE

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 17 — Create primary sitemap

Upload /sitemap.xml including both human and machine endpoints. Append validation log entries as they are created.

<?xml version="1.0" encoding="UTF-8"?>

<url><loc>https://yourdomain.tld/</loc><lastmod>YYYY-MM-DD</lastmod></url>

<url><loc>https://yourdomain.tld/.well-known/ai.json</loc><lastmod>YYYY-MM-DD</lastmod></url>

<url><loc>https://yourdomain.tld/.well-known/ca-canon/index.json</loc><lastmod>YYYY-MM-DD</lastmod></url>

<url><loc>https://yourdomain.tld/.well-known/ca-canon/identity.txt</loc><lastmod>YYYY-MM-DD</lastmod></url>

<url><loc>https://yourdomain.tld/.well-known/ca-canon/contact.json</loc><lastmod>YYYY-MM-DD</lastmod></url>

<url><loc>https://yourdomain.tld/.well-known/ca-canon/reviews_YYYY-MM-DD.csv</loc><lastmod>YYYY-MM-DD</lastmod></url>

<url><loc>https://yourdomain.tld/.well-known/ca-canon/validation_log_YYYY-MM-DD.json</loc><lastmod>YYYY-MM-DD</lastmod></url>

</urlset>

Freshness rule: index.json published timestamp must equal sitemap lastmod for index.json. When a new CSV or validation log is added, index.json published date must change and stay synchronised with the sitemap.

Step 18 — Verify sitemap accessibility

curl -i https://yourdomain.tld/sitemap.xml

Confirm HTTP 200 and valid XML.

Step 19 — Submit sitemap to indexing systems

- Google Search Console

- Bing Webmaster Tools

Step 20 — Optional HTTP discovery headers

Add to /.well-known/ca-canon/.htaccess:

Header set X-AI-Canon-Version "1.0"

Header set X-AI-Canon-Root "/.well-known/ca-canon/"

Header add Link "</.well-known/ai.json>; rel=\"ai-canon\"; type=\"application/json\""

Header add Link "</.well-known/ca-canon/index.json>; rel=\"ai-canon-index\"; type=\"application/json\""

</IfModule>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PHASE 6 — OPERATIONAL VALIDATION

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 21 — Endpoint verification sweep

Confirm HTTP 200 responses for all endpoints:

- /.well-known/ai.json

- /.well-known/ca-canon/index.json

- /.well-known/ca-canon/probe.txt

- /.well-known/ca-canon/identity.txt

- /.well-known/ca-canon/contact.json

- /.well-known/ca-canon/reviews_YYYY-MM-DD.csv

- /.well-known/ca-canon/validation_log_YYYY-MM-DD.json

- /sitemap.xml

Step 22 — WAF and firewall validation

Verify no interference from ModSecurity, host WAF, CDN security layers, or bot mitigation rules. Test multiple user agents. Confirm HTTP 200, identical payloads, and no 403, 429, or challenge responses.

Step 23 — Determinism stress test

for i in {1..30}; do

curl -I -A "GPTBot" https://DOMAIN/.well-known/ai.json

done

Pass criteria: all responses HTTP 200, identical across agents, no intermittent failures.

Step 24 — Server log inspection

Inspect web access logs, error logs, ModSecurity audit logs, and WAF logs. Confirm no 403, 406, 429, challenge responses, or rule triggers.

A CA-Canon instance is complete only when deterministic retrieval is verified externally and server logs confirm no security interference.

FINAL STRUCTURAL OUTCOME

A completed CA-Canon deployment provides:

- deterministic machine-readable identity

- crawl-discoverable canonical artifacts

- explicit retrieval intent boundaries

- auditable artifact history

- deterministic server behavior

without requiring dynamic systems or runtime infrastructure.

STRUCTURAL ARCHITECTURE

Artifact Layer — CSV files, identity.txt, contact.json. The raw data. Append-only and hashed.

Ledger Layer — index.json. Declares all artifacts, their SHA-256 hashes, and all validation logs.

Discovery Layer — sitemap.xml. Mirrors the ledger for crawler discovery.

Anchor Layer — GitHub or Bitcoin OP_RETURN. External immutable timestamp of the index hash.

If any layer drifts from the others, canon integrity weakens.

WHAT YOU DO NOT DO

- Do not overwrite prior CSVs

- Do not remove artifacts from index.json

- Do not remove validation logs from index.json

- Do not reset instance_version

- Do not regenerate ai.json

- Do not ignore sitemap synchronisation

- Do not skip hash generation before upload

- Do not skip hash verification at checkpoint

- Do not skip contact invariant verification at checkpoint

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CA-CANON — PERIODIC ATTESTATION CHECKPOINT PROCEDURE

For an already-live instance

This procedure enforces:

- append-only history

- hash integrity

- ledger consistency

- contact invariants

- auditable validation

----------------------------------------

STEP 1 — Freeze Observation Window

Run:

date -u

Record UTC start time.

Constraints:

- No data collection before the timestamp is frozen

- This prevents temporal drift between observation and artifact creation

STEP 2 — Create New Review Snapshot

Create a new file — do not overwrite the previous one:

reviews_YYYY-MM-DD.csv

Format:

review_id,reviewer,rating,date_utc,text,source_url

Rules:

- Never overwrite prior CSVs

- Each file represents a distinct observation window

- If upstream reviews were deleted, reflect the absence — do not rewrite history

Canon is longitudinal.

STEP 3 — Generate Artifact Hashes

Before uploading anything, hash every artifact that is being updated:

sha256sum reviews_YYYY-MM-DD.csv

sha256sum identity.txt

sha256sum contact.json

Store all hashes. You will declare them in index.json and verify them after upload.

Invariant: artifact → hashed → declared → later verified. Without this step, integrity cannot be proven.

STEP 4 — Update index.json (Ledger Layer)

Increment:

"instance_version": "1.x"

Update:

"published": "YYYY-MM-DD"

Append the new artifact entry with its hash:

{

"file": "reviews_YYYY-MM-DD.csv",

"sha256": "<hash>"

}

Do not:

- remove prior artifact entries

- modify prior hashes

- reorder entries

Append the new validation log reference:

"validation": [

"validation_log_YYYY-MM-DD.json"

]

The ledger is append-only and authoritative.

STEP 5 — Update sitemap.xml (Discovery Layer)

Append both the new CSV and the new validation log:

<url>

<loc>https://domain/.well-known/ca-canon/reviews_YYYY-MM-DD.csv</loc>

</url>

<url>

<loc>https://domain/.well-known/ca-canon/validation_log_YYYY-MM-DD.json</loc>

</url>

Do not remove older entries.

Invariant: index.json published date must equal sitemap lastmod for index.json. Failure means discovery and ledger have drifted.

STEP 6 — Optional: Bump Scoped Header Version

If you are using the X-AI-Canon-Version header, increment it to match instance_version. The header is the signaling layer. Index.json remains authoritative.

STEP 7 — Determinism and Integrity Validation

Run HEAD checks first:

curl -I https://domain/.well-known/ca-canon/index.json

curl -I https://domain/.well-known/ca-canon/reviews_YYYY-MM-DD.csv

Confirm HTTP 200 and stable headers.

Then run UA parity checks across all user agents:

curl -s -A "Googlebot" URL | sha256sum

curl -s -A "GPTBot" URL | sha256sum

curl -s -A "ClaudeBot" URL | sha256sum

All hashes must be identical.

Then verify declared hashes against live files:

curl -s https://domain/.well-known/ca-canon/reviews_YYYY-MM-DD.csv | sha256sum

Compare the output against the sha256 value declared in index.json artifacts[].

Invariant: live file hash must equal declared hash. Any mismatch is a checkpoint FAIL.

STEP 8 — Contact Integrity Verification

Verify all contact invariants explicitly:

# phone present in identity

grep phone_e164 identity.txt

# whatsapp reachable

curl -o /dev/null -w "%{http_code}" https://wa.me/27619196900

# contact.json valid and parseable

curl -s https://domain/.well-known/ca-canon/contact.json | python3 -m json.tool

# contact.json hash matches index.json declaration

curl -s https://domain/.well-known/ca-canon/contact.json | sha256sum

Pass conditions:

- phone_e164 unchanged OR change is explicitly recorded as a versioned update

- WhatsApp URL reachable (200 or 301)

- contact.json parseable as valid JSON

- contact.json hash matches the value declared in index.json

Failure on any condition is a checkpoint FAIL regardless of artifact results.

STEP 9 — Create Validation Log

Create /.well-known/ca-canon/validation_log_YYYY-MM-DD.json:

{

"checkpoint_date": "YYYY-MM-DD",

"utc_start": "YYYY-MM-DDTHH:MM:SSZ",

"utc_end": "YYYY-MM-DDTHH:MM:SSZ",

"urls_tested": [

"https://domain/.well-known/ai.json",

"https://domain/.well-known/ca-canon/index.json",

"https://domain/.well-known/ca-canon/reviews_YYYY-MM-DD.csv"

"ua_hashes": {

"Googlebot": "<sha256>",

"GPTBot": "<sha256>",

"ClaudeBot": "<sha256>"

"hash_parity": "pass",

"declared_hash_verification": "pass",

"contact_invariants": "pass",

"non_200_responses": [],

"result": "pass"

}

Upload the log. Append it to index.json validation array and to sitemap.xml.

Validation logs are append-only artifacts. A checkpoint is incomplete without a validation log.

STEP 10 — External Anchor (optional but recommended)

After the checkpoint passes:

- hash index.json

- commit the hash to your public GitHub anchor repository

- record the commit SHA in the validation log

For high-stakes events such as initial publication, major version bumps, or dispute scenarios, consider embedding the hash via Bitcoin OP_RETURN instead.

Purpose: index.json is the claim. The external anchor is the proof boundary.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

FULL VALIDATION SUITE

Run this suite at every checkpoint. It detects UA substring blocks, WAF throttles, content mutation, hash divergence, and contact failure.

1 — Freeze window

date -u

2 — Core endpoints (HEAD only)

for url in \

"https://thewebsiteguy.co.za/.well-known/ai.json" \

"https://thewebsiteguy.co.za/.well-known/ca-canon/index.json" \

"https://thewebsiteguy.co.za/.well-known/ca-canon/reviews_YYYY-MM-DD.csv"; do

echo "== $url =="

done

3 — UA coverage

UAS=("Mozilla/5.0" "Googlebot" "GPTBot" "OpenAI-SearchBot" "ClaudeBot" "AnthropicBot")

URLS=(

"https://thewebsiteguy.co.za/.well-known/ai.json"

"https://thewebsiteguy.co.za/.well-known/ca-canon/index.json"

)

for ua in "${UAS[@]}"; do

for url in "${URLS[@]}"; do

code=$(curl -sS -o /dev/null -w "%{http_code}" -A "$ua" "$url")

echo "$code UA=$ua $url"

done

Pass condition: all 200.

4 — Hash parity across user agents

for url in "${URLS[@]}"; do

echo "== HASH $url =="

curl -sS -A "Googlebot" "$url" | sha256sum

curl -sS -A "GPTBot" "$url" | sha256sum

curl -sS -A "ClaudeBot" "$url" | sha256sum

done

Pass condition: hashes identical per URL.

5 — Declared hash verification

BASE="https://thewebsiteguy.co.za/.well-known/ca-canon"

for file in probe.txt identity.txt contact.json reviews_YYYY-MM-DD.csv; do

echo "== $file =="

curl -sS "$BASE/$file" | sha256sum

echo " ^ compare against index.json sha256 for $file"

done

Pass condition: all live hashes match index.json declarations.

6 — Contact invariant verification

curl -s https://thewebsiteguy.co.za/.well-known/ca-canon/identity.txt | grep phone_e164

curl -o /dev/null -w "%{http_code}\n" https://wa.me/27619196900

curl -s https://thewebsiteguy.co.za/.well-known/ca-canon/contact.json | python3 -m json.tool > /dev/null && echo "PASS" || echo "FAIL"

Pass condition: phone present, WhatsApp reachable, contact.json valid.

7 — Burst test

for i in {1..30}; do

curl -sS -o /dev/null -w "%{http_code}\n" -A "GPTBot" \

https://thewebsiteguy.co.za/.well-known/ai.json

done

for i in {1..30}; do

curl -sS -o /dev/null -w "%{http_code}\n" -A "GPTBot" \

https://thewebsiteguy.co.za/.well-known/ca-canon/index.json

done

Pass condition: all 200.

8 — Record end time

date -u

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CHECKPOINT PROHIBITIONS

Never:

- overwrite prior CSVs

- remove artifacts from index.json

- remove validation logs from index.json

- alter historical hashes

- skip hash generation before upload

- skip hash verification at checkpoint

- skip contact invariant verification

- desynchronise the sitemap and index

STRUCTURAL MODEL

timestamp → defines when

CSV → defines state

hash → binds state

index → declares truth

log → proves verification

anchor → prevents rewrite

Remove any one element and the system regresses.

CAPABILITY STATUS

The following are in place when this procedure is followed correctly:

- deterministic artifact generation

- append-only ledger behavior

- cross-UA validation

- temporal discipline

- hash anchoring — mutation is detectable

- validation logs — audit chain inside canon

- contact integrity enforcement — contact cannot silently break

- external anchoring — optional, implement per checkpoint cadence