CartoQuantum 2.0 learning brief
CartoQuantum does not replace storage. It makes storage verifiable.
Core idea:
- A CQ Object carries a content ID derived from canonical content.
- CQ-C14N/1 defines the exact canonical bytes used for identity.
- Servers, databases, files, QR codes, messages, and adapters can store or transport CQ Objects.
- The carrier is not the source of truth. The object can be verified independently.
- Content ID proves integrity, not semantic truth.
- derived_from is a provenance claim. Authentic provenance requires signatures, attestations, logs, timestamps, and policy.
- CABAB is an optional upper layer for coordination and settlement. It consumes and emits CQ Objects but does not change CQ identity.
Minimum object:
- cq: "2"
- id: cq:sha256:<digest>
- kind
- coords
- payload
- provenance: parents, derived_from, caused_by
- operations
- signatures
- lifecycle
Most important invariant:
Never update an emitted object. Create a new object and preserve provenance.derived_from.
Failure invariant:
Do not stop at "corrupt". Emit an idempotent validation report or quarantine object with a recommended recovery route.
Documentation style:
Explain every concept with simple words first, then minimal flow, then protocol boundary, then object mapping, then idempotency.
Prompt de implementacion
Implement the CartoQuantum 2.0 minimum CQ Object contract.
Required behavior:
- Create and validate CQ Objects with cq, id, kind, coords, payload, provenance, operations, signatures, lifecycle.
- Canonicalize with CQ-C14N/1.
- Accept only null, booleans, strings, objects, arrays, and safe integers.
- Reject floats, -0, and integers outside [-9007199254740991, 9007199254740991].
- Canonicalize 1, 1.0, and 1e0 to 1.
- Perform no Unicode normalization.
- Compute content ID as cq:sha256:<lowercase-hex-digest>.
- Exclude id and signatures from the hash input.
- Normalize provenance parents, derived_from, caused_by, lifecycle supersedes/revokes, and operations inputs with normalize_string_set.
- Never mutate an emitted object; derive a new object and preserve derived_from.
- Treat signatures as crypto-agile metadata that do not alter content identity.
- Treat derived_from as a declared edge, not proof that the transformation really happened.
- Require signatures and policy before accepting provenance as trusted.
- On failure, emit cq.validation_report/1 or cq.quarantine/1 with a deterministic cqop:sha256 idempotency key.
- Choose a recovery route: accept, quarantine, readdress, repair_derive, request_parent, fork_from_last_valid, reject_for_operation.
Do not add blockchain, consensus, wallet, CABAB runtime, storage-provider coupling, or custom cryptography.
Use the test vectors before claiming compatibility.
Checklist de validacion
CQ 2.0 compatibility checklist
Object model:
[ ] Supports cq: "2".
[ ] Requires kind, coords, payload, provenance, operations, signatures, lifecycle.
[ ] Uses provenance.derived_from for transformation lineage.
[ ] Does not treat derived_from alone as authentic provenance.
Canonicalization:
[ ] Rejects non-JSON values.
[ ] Implements CQ-C14N/1.
[ ] Accepts only null, booleans, strings, objects, arrays, and safe integers.
[ ] Rejects floats, -0, and unsafe integers.
[ ] Canonicalizes 1, 1.0, and 1e0 to 1.
[ ] Performs no Unicode normalization.
[ ] Sorts object keys lexicographically by Unicode scalar value.
[ ] Preserves non-set array order.
[ ] Normalizes designated string-set fields before hashing.
[ ] Removes only id and signatures before hashing.
Content ID:
[ ] Computes SHA-256 over UTF-8 canonical JSON bytes.
[ ] Emits lowercase hex.
[ ] Formats ID as cq:sha256:<digest>.
[ ] Adding a signature does not change the content ID.
Derivation:
[ ] Does not update historical objects.
[ ] Creates a new object for every transformation.
[ ] Adds source IDs to provenance.derived_from.
Tests:
[ ] Root vector ID matches.
[ ] Derived vector ID matches.
[ ] Reordered object keys produce the same ID.
[ ] Reordered derived_from entries produce the same ID.
[ ] Reordered operations[*].inputs entries produce the same ID.
[ ] 1, 1.0, and 1e0 produce the same canonical bytes.
[ ] -0, 1.25, and 9007199254740992 are rejected.
[ ] Unicode escaped/literal equivalents produce the same canonical bytes.
[ ] U+00E9 and e + U+0301 produce different canonical bytes.
[ ] Changing payload changes the ID.
Recovery:
[ ] Validation returns structured status, not just true/false.
[ ] id_mismatch includes declared_id and computed_id.
[ ] Every failed validation has a cqop:sha256 idempotency key.
[ ] Same failure produces the same idempotency key.
[ ] Failure can emit cq.validation_report/1.
[ ] Unsafe input can emit cq.quarantine/1.
[ ] Recovery chooses an explicit route.
CABAB:
[ ] Treats CABAB as optional upper layer, not CQ identity.
[ ] CABAB objects are ordinary CQ Objects.
[ ] Represents the consent handshake: A proposes, B accepts, A confirms close.
[ ] CABAB uses derived_from for intents, commitments, policies, and evidence.
[ ] CABAB supports cabab.intent/1, cabab.commitment/1, cabab.consent_close/1, settlement and dispute objects.
[ ] CABAB operation keys use cqop:sha256.
[ ] CABAB settlement requires policy and does not prove semantic truth alone.
Prompt de recovery
Implement CartoQuantum idempotent recovery.
Required behavior:
- Validate input into a structured report: status, declared_id, computed_id, idempotency_key, recommended_route, reasons.
- Compute idempotency_key as cqop:sha256:<digest> over CQ-C14N/1 canonical JSON with scope and input.
- For id_mismatch, include both declared_id and computed_id.
- For malformed input, preserve evidence as raw_ref when available and emit quarantine.
- For missing_parent, do not invent lineage; request_parent or fork_from_last_valid.
- For expired, keep the object historically but reject_for_operation.
- Re-running the same failed validation must produce the same idempotency key.
- Recovery outputs should themselves be CQ Objects whenever possible.
Recovery routes:
- accept
- quarantine
- readdress
- repair_derive
- request_parent
- fork_from_last_valid
- reject_for_operation
Prompt de trust
Implement CartoQuantum trust evaluation.
Separate these questions:
- Content ID: Is this exact content?
- Signature: Who asserts this object?
- Provenance: What does it claim to derive from?
- Policy: Do I accept that claim?
- Truth: Is the semantic claim correct? This is out of scope for CQ alone.
Required behavior:
- Recompute content ID before any trust decision.
- Verify signatures using the selected signature suite.
- Treat provenance.derived_from as a declared edge until policy accepts it.
- Reject or quarantine malicious provenance claims when signer, attestation, parent availability, or allowed transformer policy fails.
- Preserve forks and equivocation as separate valid objects unless policy declares a winner.
- Never present CQ as proving semantic truth by itself.
Recommended landing phrase:
The evidence of identity and provenance travels with the data.
CQ-C14N/1 vectors
A - object keys reordered -> same ID
B - derived_from reordered/duplicated -> same ID
C - 1, 1.0, 1e0 -> same canonical bytes: {"x":1}
D - {"x":-0} -> reject
E - "\u00e9" and literal U+00E9 -> same canonical bytes
F - U+00E9 and e + U+0301 -> distinct IDs
G - signature added -> same content ID
H - payload modified -> distinct content ID
I - {"x":9007199254740992} -> reject
J - {"x":1.25} -> reject
CABAB
CABAB layer brief
CABAB is portable consent between parties.
Plain version:
A -> B: A proposes an agreement and signs it.
B -> A: B accepts that exact proposal, or accepts with explicit conditions, and signs it.
A -> B: A confirms receipt of B's acceptance and signs the close.
Result:
Not "the server says they agreed". A CABAB close is a CQ chain where both parties signed compatible statements about the same agreement.
Boundary:
- CABAB uses CQ Objects as evidence.
- CABAB does not change CQ-C14N/1, content IDs, signatures, lifecycle, recovery, or trust.
- CABAB settlement is a policy decision over accepted evidence.
- CABAB is not blockchain, consensus, wallet, token, custody, payment rail, or storage.
Minimum CABAB object kinds:
- cabab.intent/1
- cabab.commitment/1
- cabab.consent_close/1
- cabab.settlement_report/1
- cabab.receipt/1
- cabab.dispute/1
Minimal flow:
1. A emits cabab.intent/1.
2. B emits cabab.commitment/1 derived from A's intent.
3. A emits cabab.consent_close/1 derived from B's commitment.
4. A verifier emits settlement_report or dispute.
5. Preserve all evidence IDs in provenance.derived_from.
6. Use cqop:sha256 idempotency keys scoped as cabab.settlement/1.
Implementation gate:
Do not implement a CABAB runtime or network until CQ Object, CQ-C14N/1, recovery, and trust are stable.
Ruta de aprendizaje
1. Modelo
Entender el objeto inmutable y sus campos obligatorios.
2. Identidad
Canonicalizar, hashear y verificar `cq:sha256`.
3. Procedencia
Crear derivados con `provenance.derived_from`.
4. Validacion
Pasar vectors antes de conectar adapters o runtimes.
5. Recovery
Emitir reportes idempotentes y rutas de escape.
6. Trust
Aceptar procedencia solo con firmas y policy.
7. CABAB
Coordinar settlement usando CQ Objects como evidencia.