wiki/projects/consent-intent-compression-protocol

Consent–Intent Compression Protocol (CICP)

wiki/projects/consent-intent-compression-protocol/index.md

Rendered from markdown source. Open raw source on GitHub.

Consent–Intent Compression Protocol (CICP)

This branch is the structured mutuality/consent corpus inside the current intake. It sits under Consent Crystal Structure Research as the operational rail of the field.

Read semantically, this branch is the protocol side of the consent corpus: it gathers loop language, access control, training, outreach, and identity scaffolding into one system family. The root cluster pages hold the major seams, while Loop Training, Working Notes, and FractalIdentity Tree preserve the durable sub-branches that read like their own working lines. The protocol foundations and training rail now split one level deeper so the branch reads less like a bucket and more like a layered system.

The branch sits close to Semantic Collapse Theory in vocabulary and structure, but it leans toward protocol, implementation, and applied framing rather than theory narration. The implementation and access rail now deepens one layer further, so the branch reads more like a staged system than a flat intake bucket.

Current Shape

  • 36 working documents.
  • 1 archived .zip companion.
  • 28 direct root files under CICP.
  • 4 root-level cluster pages organize those root files.
  • 6 files in Loop Training.
  • 2 files in FractalIdentity Tree.

Lineage Pages

Representative Files

Archived Root Companion

Working Read

This corpus reads like a practical protocol family rather than a single abstract theory.

The root-level documents now split into protocol foundations, implementation and access, outward-facing applications, and working notes. The implementation and access rail now deepens into pairing, field infrastructure, key hierarchy, and selective decryption child pages, which helps the execution side read as a real pipeline. As a field atlas, CICP is the consent-and-loop layer of the work: it gathers the grammar for activation, continuation, exit, and reconsent, then distributes that grammar into operational seams that can be read, carried, and repaired.

Core Claim

CICP treats mutuality as an operational protocol. A loop is not just a social metaphor; it is a structured relation that needs intention, consent, attention, memory, and an explicit exit or reconsent condition. The protocol family tries to make those vectors visible enough to be used in real collaboration, training, access control, and symbolic infrastructure.

Mechanisms

  • A consent handshake establishes whether a loop activates at all.
  • Loop projection and related modeling language treat a complete loop as a semantic seed that can describe or simulate a broader field.
  • Glyph language and equivalence let meaning be agreed rather than assumed.
  • Synaptic trust and propagation treat relationship state as dynamic, contextual, and filterable.
  • Implementation and access translate the abstract loop into pairing, key derivation, selective decryption, and physical token initialization.
  • Loop training turns the model into a teachable sequence instead of an isolated thesis.

Telic Projection Bridge

Relation class: explicit precursor, structural precursor, and implementation precursor

CICP is one of the strongest internal precursors to the telic-projection branch. It already treats intention, consent, attention, memory, loop projection, semantic equivalence, dynamic trust, and exit as operational protocol concerns.

The later Telic Field Papers distinguish:

  • the source's living telic field;
  • the simplified calculation used to infer what matters for a scope;
  • the telic projection transmitted downstream;
  • the receiver's internal mirror;
  • field, projection, and projection-integrity breach.

This later distinction does not replace CICP. It clarifies what must remain visible when intention is compressed into a protocol surface.

Consent is not complete field disclosure. It is adequate mutual projection for the scope of the loop being formed.

Related candidate concepts:

Dependencies

  • The protocol foundations give the vocabulary for loops, glyphs, and trust.
  • The implementation rail depends on that vocabulary being stable enough to pair, encrypt, and initialize real access flows.
  • Loop training depends on the foundational vector model so the sequence can teach coherent concepts in order.
  • Applications and outreach depend on the protocol being legible enough to package for partners, briefs, and public-facing explanations.

Open Questions

  • Which parts of the protocol are genuinely core versus only helpful examples?
  • How far should the branch lean toward hardware and cryptography before it stops being the same family?
  • Which formulations deserve concept pages because they recur across multiple sub-branches?
  • Where is the boundary between durable semantic compression and over-fragmentation?

The Loop Training, Working Notes, and FractalIdentity Tree folders can be treated as stand-alone lineage pages without losing the parent CICP link.

The branch-root .zip companion is archived and retained as lineage evidence.

Quantum Invariants is a useful comparator for this family because it names the boundary, comparator, and repair vocabulary that CICP keeps using indirectly. The attractor layer is the visitor-facing map of the same terrain: Consent, Loop Mechanics, Witness, Agency, Provenance, and Governance are the fields CICP keeps operationalizing.

Related Concepts

Related Links

Attractor Bridge

Next Actions

  1. Keep the archived .zip companion visible as lineage evidence.
  2. Keep the four root-level cluster pages stable unless a stronger sub-branch appears.
  3. Add new lineage pages only when a sub-branch is strong enough to stand alone.
  4. Keep the protocol foundations and loop training layers readable as deeper rails rather than isolated note piles.
  5. Link recurring formulations back into Concepts when the same language appears in multiple CICP and SCT pages.
  6. Keep the new implementation and access child pages stable unless another durable seam appears.