proto.computer / companion doc

abstraction matrix

this is the ladder doc. it keeps the same world visible across business language, builder language, formal language, runtime language, and viewer language. it also makes the missing boundary explicit: sources compose into bindings and ports; faces admit datums; protos are the glowing membranes where those datums can bind to an existing epi or birth a new one.

source → binding → port → face → datum → proto bay → epi / status → projection / effect
ceo → builder → formal → runtime → viewer

cross-section viewer

same world, four cuts. the first two are the ones that were underspecified before: source composition and the proto membrane.

outside sources partner qr surface sales floor / printed code whatsapp webhook headers, auth, json body csv / sheet rows file drop / sync pull human desk manual entry / call notes binding rack credential protocol parser matcher admit policy effect policy port http in port file in port human desk face semantic aperture datum admitted material proto membrane / glowing orb proto bay keyspace where epis bind or are born bind rule birth rule resident epis + relations process / status track screen projection dock effect / outbox source composition lives on the left: concrete systems, auth, parsers, matchers, admit policy. crossing the orb is the semantic boundary: not every caught signal becomes an epi.
the datum is not yet business truth. a face can catch many foreign signals; the proto membrane is where local meaning is granted. bind rules attach a datum to an existing epi; birth rules let a datum instantiate a new epi. that is why the proto reads better as a glowing orb than a dead schema box.
one motion: partner floor inquiry becomes a live credit request operator builder formal runtime viewer “someone scanned our qr and started a financing request.” question: what just happened in my business? qr face + whatsapp face origination entry route credit_request proto origination track question: which pieces must exist in the world? d admitted from face ρ = entry.from_partner_qr ι = ensure request context emit whatsapp-flow obligation question: what is legal? one attempt in intake lane commit receipt + durable ℓ ο queued for delivery projection invalidated question: what committed and what is still owed? pulse enters face proto orb warms track gets a new token board card appears question: what can a human see and scrub through? the event changes vocabulary as altitude changes, but the causal skeleton should stay continuous.
this is the breadcrumb rule: as abstraction rises, the lower layer must remain legible. the builder should still see the formal nouns hiding under the product nouns, and the viewer should still hint at the runtime and formal facts it is staging.
authored world what the builder declares sources + bindings + faces protos + relations processes + effects + views zones + anchors + tracks + screens compiled world what the machine actually is κ law χ machinery μ readout rules ν staging σ set / shared scene basis live world what operators and viewers touch d arrivals • α attempts • λ lanes ξ receipts • ℓ durable record ο obligations • retries • lag ω projections • ψ viewer film compile instantiate
authored is ergonomic, compiled is ontological, live is operational. the abstraction matrix exists so those zooms do not drift into three different theories.
corrected reading of “qr to request”: qr is a source surface, not automatically the business fact partner store qr surface source whatsapp entry face + binding headers, auth, parser, matcher determine if anything is admitted d admitted message / payload / matched event ρ origination.entry from_partner_qr chosen route credit_request proto birth or bind happens here origination track dock send flow screen pipeline view operator “someone started financing” builder source + face + route + proto + track + dock + screen formal d is the admitted event, not “the qr” in the abstract runtime receipt + obligation + projection refresh viewer orb lights up; board gains a card
this is the corrected finexa read: the qr surface is a source. the business fact is a request epi inside the credit_request proto. the system may admit a whatsapp message, a flow payload, or another matched event as d; whichever object is admitted still has to pass a route and the orb membrane before the request exists in-world.
boundary / formal cut routing / builder cut runtime / process cut viewer / staging cut proto membrane / durable ontology

matrix a — altitudes

altitude core question native nouns main failure if drift happens
operator / ceo / cto what are the core things in my business, how do they move, and where is work stuck? customers, requests, loans, teams, approvals, exports, dashboards tool topology starts masquerading as business truth
builder what durable kinds, faces, tracks, docks, and screens must exist to model that world? source, binding, face, anchor, track, dock, screen the scene looks nice but no longer compiles to semantics
formal how does caught outside material become local semantic fact? datum, route, proto bay, epi, process, effect, projection a caught signal is mistaken for an already-meaningful record
runtime what attempted, committed, failed, retried, or is still owed? attempt, lane, receipt, obligation, lag, outbox, replay durable truth and delivery mechanics get fused into one blob
viewer how do i see why this happened through time without drowning in rows? scene, pulse, overlay, track occupancy, orb glow, timeline, lens pretty film with no breadcrumb back to record and law

matrix b — six axes

axis what it asks formal focus builder surface viewer symptom
ontology what durable things exist here? proto → epi → relation anchor placement and bridge declarations which orbs, links, and resident counts are visible
boundary what may enter or leave, and by which meanings? source → binding → port → face → datum faces, port racks, binding cards, gates ingress pulses, rejected pulses, dock activity
time what happened, when, and in what order? arrival → attempt → commit → history tracks, lanes, replay windows timelines, scrubbable traces, occupancy
control who may move a thing, and under what rules? process → status → obligation → effect tracks, status stops, dock policies status beads, beacons, blocked handoffs
visibility what must be legible to humans and machines? projection → readout → picture screens, filters, lenses, exports boards, charts, inspectors, world overlays
binding what concrete system instance is this semantic face attached to? deployment binding and auth state binding racks and source cards connector health, freshness, auth warnings

matrix c — boundary ladder

layer question builder noun formal noun failure mode
source where in the outside world does the signal originate? source card foreign origin assuming the protocol endpoint is the business source
binding which concrete credentials, headers, parser, and deployment wire this source to us? binding rack binding confusing abstract interface with one deployed instance
port which ingress or egress slot is used? port typed port hiding protocol shape inside a generic magic tunnel
face through which semantic aperture does the world inspect it? face face making every endpoint its own ontology
admission does anything here count as local datum at all? gate / admit policy datum treating every caught packet as meaningful d
proto membrane which durable kind could this datum mean in this world? anchor orb proto bay equating schema with already-existing instance
bind rule can the datum resolve to an existing resident? lookup socket bind duplicate residents and key collisions
birth rule may the datum create a new resident? birth socket instantiate epi ghost records born from weak matches
motion what lawful lifecycle does the resident now inhabit? track process / status state changes with no explicit machine
outside consequences what must the world now show or do? screen / dock projection / effect / obligation delivery side-effects smuggled into semantic truth

matrix d — why protos are orbs

a proto is not just a schema sketch. it is the place where a world grants semantic residency. that is why the anchor works better as a glowing orb:

membrane

outside material stays outside until the membrane admits it. the orb says “local meaning starts here.”

bay

the shell implies intake bays, lookup sockets, birth rules, and relation spokes, not a flat dead document icon.

keyspace

a resident epi lives in a keyspace. the orb visually holds those residents and their identity rules.

fractal repeat

interfaces compose into ports; ports into faces; faces into orb bays; orbs into bridges and tracks. same grammar up and down.

proto = membrane
      + intake_bays
      + keyspace
      + bind_rules
      + birth_rules
      + relation_sockets
      + process_sockets
      + projection_refs

matrix e — source composing

“implementing an api” is not one monolithic thing. in this grammar it decomposes into concrete boundary parts, all of which can be visualized and reasoned about: 

source_composition =
  source_kind
  + credential
  + protocol
  + parser
  + matcher
  + admit_policy
  + bind_rule
  + birth_rule
  + effect_policy

inbound and outbound are symmetric enough to rhyme: 

inbound  = source → binding → port → face → datum → proto bay
outbound = obligation → dock → port → binding → target system

this keeps “runtime magic” honest. the builder can still hide most of it behind a face in basic mode, but the grammar remains there when you need to descend.

matrix f — vocabulary ladder

plain business word builder word formal word runtime word viewer word
business / operationworldworldcompiled worldscene
channel / endpoint / pagefacefaceadmission pointportal / kiosk
connected account / deployed integrationbindingbindingconnector statehealth badge
message / file / form payloadinputdatumarrivalpulse
record kindanchorprotoregistry keyspaceorb
record / case / loan / requestinstanceepiresidentresident bead / selected token
workflowtrackprocessexecution pathrail / halo path
stagestopstatuscurrent positionstatus bead
actiondockeffectobligation / outbox itembeacon / outbound station
dashboard / report / api readscreenprojection / viewreadoutlens / wall / board
audit trailtimelinehistoryreceipts + durable ℓtrace film

matrix g — authoring prompts

ontology prompts

1. what durable things exist?
2. how do you recognize each?
3. when is one born vs merely updated?
4. which relations matter operationally?

boundary prompts

5. what sources exist outside?
6. which bindings and ports attach them?
7. what gets admitted as d?
8. which proto bay can each d cross?

motion + view prompts

9. what lawful tracks exist?
10. what must the world do outward?
11. what must be seen, filtered, replayed?
12. what should the 3d world make obvious?
user narrative → world spec → compile → instantiate → run → observe → render