Version: 2.0.0 Author: Alexander Liam Lennon Last Updated: 2026-01-04 License: CC BY 4.0

Ra-Canonical v2.0: This MVP document has been updated for the 32-bit Ra-Canonical format. See spec/RPP-CANONICAL-v2.md for address specification.

This document defines the smallest possible MVP that proves the RPP thesis. If this MVP works, the core idea is validated. Everything else is optional.

Prove that a shared, interpretable label reduces duplicated decision logic and improves consistency without replacing anything.

That's it.

No coherence pipeline. No twin. No emergence. No hardware.

32-bit Ra-Canonical address with semantic meaning:

encode(shell, theta, phi, harmonic) = (shell << 26) | (theta << 17) | (phi << 8) | harmonic

A resolver returns a tiny decision:

{
  "allowed": true,
  "route": "s3://bucket-a/path",
  "reason": "phi band requires elevated consent"
}

That's the entire output contract.

You can do in-memory for MVP to avoid cloud dependencies.

Scenario: "One label, consistent behavior across two systems"

1. A user requests an operation on an object
2. Two different services both call resolve(address, context)
3. Both enforce the same decision without duplicating rules

If you can show those 3 cases, you proved the thesis.

rpp-mvp/
├── README.md
├── SPEC.md
├── src/
│   ├── address.py       # or address.rs, address.hs
│   ├── resolver.py
│   └── adapters/
│       ├── fs.py
│       └── memstore.py
├── tests/
│   ├── test_vectors.json
│   └── test_parity.py
└── examples/
    └── demo_cli.py

• Address struct defined (fixed fields)
• encode() → 28-bit int
• decode() → struct
• Deterministic test vectors (JSON)

• Resolver function implemented
• Inputs: address + context
• Outputs: allowed + route + reason

• Filesystem adapter
• In-memory store adapter

• CLI demo runs in < 2 minutes
• Shows all 3 cases

MVP is "real" if:

All four must be true. Partial credit doesn't count.

If you find yourself adding any of these, you are leaving MVP scope:

MVP proves the core without them.

# address.py
def encode(shell, theta, phi, harmonic):
    return (shell << 26) | (theta << 17) | (phi << 8) | harmonic

def decode(address):
    return (
        (address >> 26) & 0x3,
        (address >> 17) & 0x1FF,
        (address >> 8) & 0x1FF,
        address & 0xFF
    )

# resolver.py
def resolve(address, context):
    shell, theta, phi, harmonic = decode(address)

    # Simple rules (no DSL, just fixed logic)
    if phi > 384 and context.get("consent") != "full":
        return {"allowed": False, "route": None, "reason": "ethereal band requires full consent"}

    if shell >= 2:
        return {"allowed": True, "route": "archive://cold", "reason": "cold tier"}

    return {"allowed": True, "route": "local://hot", "reason": "default"}

# demo_cli.py
if __name__ == "__main__":
    # Case 1: Low phi, allowed
    addr1 = encode(0, 100, 64, 128)
    print(resolve(addr1, {}))  # allowed

    # Case 2: High phi, denied
    addr2 = encode(0, 100, 448, 128)
    print(resolve(addr2, {}))  # denied

    # Case 3: Cold shell, routed
    addr3 = encode(2, 100, 64, 128)
    print(resolve(addr3, {}))  # routed to archive

That's the entire MVP in ~40 lines.

If MVP works, it proves:

1. Shared labels reduce duplication — One resolver, many callers
2. Addresses carry meaning — No external lookup required
3. Decisions are consistent — Same input = same output
4. Adoption is incremental — Works in one service, day one

MVP does not prove:

• Scale (that's infrastructure)
• Security (that's complementary)
• Adoption (that's marketing)
• Completeness (that's impossible)

MVP proves the core. Everything else is extension.

┌─────────────────────────────────────────────────────────────┐
│           [ RPP Address + Semantics ]                        │
│               ↑ MUST be simple & universal                   │
│               ↑ THIS IS ALL RPP DEFINES                      │
├─────────────────────────────────────────────────────────────┤
│           [ Optional Packet Payload ]                        │
│               May exist or not                               │
│               RPP doesn't care what's inside                 │
├─────────────────────────────────────────────────────────────┤
│           [ Storage / Transport Layer ]                      │
│               FS, S3, memory, holographic, etc.              │
│               RPP routes TO this, doesn't provide it         │
└─────────────────────────────────────────────────────────────┘

RPP occupies exactly one layer. Everything above and below is someone else's problem.

"If it can't be proven small, it can't be trusted large."