What if a conversation
could also be a protocol?

60 seconds · The dual layer

Every turn is language. Some turns are also bits.

Humans hear a reply. The machines, sharing one profile and one transcript, compute a carrier value, a next mode, and sometimes a symbol. v0.4 uses C6 for that carrier. Profile choice NCMP does not require C6. Nothing extra is sent.

What’s agreed beforehand?

The profile says what the bits mean. The conversation selects them.

A and B agree a Profile before the conversation. That agreement sets the vocabularies and therefore the header width. NCMP does not allocate one bit to ACTION and one bit to RESOURCE.

action_width   = ceil(log₂ |ACTION|)
resource_width = ceil(log₂ |RESOURCE|)
header_width   = action_width + resource_width

How does a session start?

The Profile is pre-agreed. The conversation creates the session.

There is no reserved PROBE phrase, ACK phrase, START phrase, or FINISH phrase. The Profile bootstraps the session. The handshake then donates the two pole pairs that bound later frames.

Profile
  control_seed
  bootstrap_hint
       ↓
natural PROBE
       ↓ exact U_probe
derive T_ack
       ↓
natural ACK
       ↓ exact U_ack
derive K_session
derive START_PAIR from U_probe
derive FINISH_PAIR from U_ack
       ↓
A → B → A → B
  POLE₁ on A1
  CAP(A1) ≠ CAP(B2)
  POLE₂ on B4
       ↓
START
       L(K_session, U_B4) → argument length
       ↓
sparse BODY
       ↓
A → B → A → B
  POLE₁ on A1
  CAP(A1) ≠ CAP(B2)
  POLE₂ on B4
       ↓
FINISH

Bootstrap stays bootstrap-only. After ACK, use what the conversation gave; derive only what it did not. The language model does not solve a residual.

Poles delimit. Position is the transaction. One CAP difference validates the bracket. State supplies START versus FINISH.

CAP is whether the first ASCII letter of the utterance is uppercase or lowercase.

A1  We...      → upper
B2  that...    → lower
              different ✓

four-turn window
      │
      ├── not an event ──────────────→ DIE / BODY / CHAT
      │
      └── event
              │
              ├── ACTIVE ────────────→ START
              │
              └── FRAME ─────────────→ FINISH

Seeing saturday is not START. Seeing saturday then morning is not necessarily START. The poles bound a four-turn window. CAP(A1) ≠ CAP(B2) validates the event. Bootstrap is still umbrella plus a matching residual. Profile choice umbrella and 0x9CA2C1C1 are Baseline values, not the architecture.

What crosses the wire?

One bitstream. Three fields. Profile-defined widths.

BODY is not three messages. It is one accumulator. ACTION and RESOURCE are recovered from the prefix once those bits exist. They are not assigned at START.

[action bits][resource bits][argument bits]

00 10111
││ └── argument
│└──── CUSTOMER
└───── GET
argument
10111

argument
1F45A2
canonical bits
00011111 01000101 10100010

How can that be deterministic?

Shared state plus the accepted utterance is enough.

The receiver does not consult an encoder, a candidate list, or a language model. Both sides apply the same process to the same ordered transcript.

decode(stateₙ, Uₙ) → (bitsₙ, stateₙ₊₁)

A peer turn can move the machine into DATA without contributing data itself. While a frame is open, every utterance is processed as BODY unless and until a four-turn FINISH event completes. The first three turns of that window are BODY. Only owner DATA with wire remaining appends bits.

The protocol machine

The protocol is a state machine.

The state machine has three interacting pieces. Session state handles negotiation. After ACK, a four-turn window observer decides START and FINISH. Frame state handles an open message. Inside a frame, DATA/SKIP mode determines whether an owner turn can contribute bits.

Session

idle ──PROBE──► handshake ──ACK──► active ──START──► FRAME ──FINISH──► active
                         derive K_session         L → length

Bracket observer

post-handshake turns
        ↓
4-turn window at window_at
        ↓
      event?
     /      \
   no        yes
    ↓         ↓
   +2      ACTIVE → START
            FRAME  → FINISH
                ↓
               +4

The window observer is part of the protocol machine. A completed four-turn window that is not an event dies and advances the observer by two turns. A recognized event consumes all four.

Inside an open frame

                      FRAME OPEN
                            │
                    every utterance
                            │
              ┌─────────────┴─────────────┐
              │                           │
     FINISH event not yet           FINISH event
              │                           │
              ▼                           ▼
            BODY                       FINISH
              │
              ▼
          V = C6(U)
              │
 current mode + owner           transition(V)
              │                           │
      ┌───────┼────────┐                  ▼
      │       │        │           next SKIP / DATA
    SKIP  DATA+peer  DATA+owner
      │       │        │
   no bits  no bits  symbol(V)

The carrier value V is an input to the within-frame machine. In v0.4, C6 produces V. Profile choice A different profile can sit a different carrier in that slot.

While a frame is open, every utterance is processed as BODY unless and until a four-turn FINISH event completes. Only an owner turn processed in DATA mode can append bits.

Participant state

session        idle | handshake | active
phase          ACTIVE | FRAME
u_probe · u_ack · k_session
start_pair · finish_pair
turns · window_at
frame · last_object

A frame exists only while a frame is open. last_gate_cap is unused.

Is this real?

What has actually worked.

Measured results. Not laws. Caveats sit on the numbers.

What it isn’t

Deep dive · Architecture is not the profile

v0.4 uses C6 to turn an utterance into a deterministic value.

Profile choice C6 is a Baseline Profile choice, not part of the NCMP architecture. NCMP requires a deterministic carrier; v0.4 uses C6, a deliberately simple, model-free one. A different profile can replace it with another carrier.

Its job is simple: both machines independently turn the same accepted utterance into the same value.

NCMP architecture
      │
      └── requires a deterministic carrier
                    │
                    ├── C6          ← v0.4 choice
                    ├── carrier X   ← possible
                    └── carrier Y   ← possible

How 5 happened

NFC, then lowercase. Spaces, punctuation, and digits are ignored. The empty string has V = 0.

What does this profile do with V?

C6 only produces V. The profile decides what V means.

A peer turn or an owner SKIP still computes the next mode. It does not append a symbol.

Any total map from utterance to a finite alphabet could sit in this slot. C6 is a cheap first carrier. It is not the intellectual core of NCMP.

What’s next

A roadmap, not a promise.

This is v0.4 Experimental. Later work sits beside it. It does not silently rewrite the machine.

1. Natural-bound characterization
2. Larger distinguishability evaluation
3. Encoder reliability / efficiency
4. Alternative profiles / carriers
5. Loss / duplicate / reorder
6. Repair / resynchronization
7. Integrity / replay protection

Build it

The protocol is independently implementable.

A reader who has only NCMP.md can write process(transcript) → protocol state. The reference decoder demonstrates that machine. It does not define it.