Review: Case Studies for Application Architecture (12 Primitives)
Status: Critical review. Testing {Ct, Sh, Ac, Mt, Pg, Ch, Pc, Pn, Bn, Au, Hs, Ev} against diverse and exotic software applications. Looking for systems that break the model.
1. Methodology
For each system: position it in the 12-primitive lattice, check for primitives that don't apply, check for concerns that aren't captured, and assess whether the positioning is structurally informative (does it tell us something real about the system?).
Deliberately including exotic/edge cases beyond mainstream applications.
2. Standard applications (sanity check)
2.1 Gmail (web email)
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | Full | Messages, contacts, labels, threads, attachments |
| Sh | 4 | Message schema, thread structure, label taxonomy |
| Ac | Full | Search (Google-grade), label filtering, conversation threading |
| Mt | 3 | Send, archive, delete, label, star — typed operations |
| Pg | 3 | New message notifications, label count updates |
| Ch | 3 | Eventual consistency across devices/tabs |
| Pc | 3 | Keyboard shortcuts, click, touch, compose events |
| Pn | 4 | Rich HTML rendering, conversation view, responsive layout |
| Bn | Full | Client ↔ API ↔ services ↔ storage ↔ spam ML ↔ push |
| Au | 3 | Google account, delegated access, confidential mode |
| Hs | 2 | Undo send (timed), trash (30 day), no version history on messages |
| Ev | 2 | Filters/rules, smart categories, priority inbox (algorithmic sorting) |
Assessment: Maps cleanly. All 12 primitives apply. The positioning IS informative — Gmail's strength is Ac (search), Bn (distributed architecture), and Pn (rich presentation). Its weakness is Hs (minimal history) and Ev (basic rules). Matches real user experience.
2.2 Postgres (relational database)
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | Full | Rows, columns, tables, JSON, binary objects |
| Sh | Full | SQL DDL, constraints, foreign keys, check constraints |
| Ac | Full | SQL queries, indexes, full-text search, GIS |
| Mt | Full | INSERT/UPDATE/DELETE, transactions, triggers |
| Pg | 2 | LISTEN/NOTIFY, logical replication, triggers |
| Ch | Full | ACID transactions, MVCC, serializable isolation |
| Pc | 1 | Receives SQL commands over connections — batch input |
| Pn | 0 | No direct presentation to humans — returns result sets to client apps |
| Bn | 2 | Client-server protocol, replication |
| Au | 3 | Roles, row-level security, connection authentication |
| Hs | 2 | WAL, point-in-time recovery — but not application-level version control |
| Ev | 3 | Materialized views, computed columns, stored procedures, triggers |
Assessment: Maps cleanly. Pc at 1 and Pn at 0 correctly capture that Postgres is a backend service — it doesn't interact with humans directly. Ev at 3 captures the computation Postgres DOES do (views, procedures). Structurally informative.
3. Exotic cases
3.1 Bitcoin / Blockchain
A decentralized ledger with no central authority, no server, append-only mutations.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | 3 | Transactions, blocks, UTXOs, scripts |
| Sh | 3 | Transaction format, block structure, script language |
| Ac | 2 | UTXO lookup by address, block by hash/height — limited query |
| Mt | 1 | APPEND ONLY — transactions are immutable once confirmed. No update/delete. |
| Pg | Full | Transaction broadcast, block propagation across P2P network |
| Ch | Full | Nakamoto consensus — probabilistic finality, longest chain rule, Byzantine fault tolerance |
| Pc | 2 | Receives transactions from wallets/nodes — event-driven |
| Pn | 0-1 | No presentation — wallet apps provide UI separately |
| Bn | Full | Fully P2P, every node is equal, dynamic mesh |
| Au | Full | Cryptographic — private keys, signatures, script-based authorization. Self-sovereign. |
| Hs | Full | The blockchain IS the history — every transaction ever, immutable, reconstructible |
| Ev | 3 | Script evaluation, smart contracts (Ethereum), transaction validation |
Assessment: Maps well. The unusual features are captured:
- Mt at 1 (append-only) correctly reflects immutability — blockchain doesn't UPDATE, it APPENDS
- Ch at Full (consensus) correctly reflects that coherence IS the core innovation
- Hs at Full (the chain IS history) — blockchain is a history-first system
- Pn at 0-1 correctly reflects that blockchain nodes have no presentation — wallets are separate apps
- Au at Full (cryptographic self-sovereign) — correctly reflects the key innovation
Does it break the model? No. The positioning is informative and distinctive. Blockchain is structurally unique: {Mt1, Pg-Full, Ch-Full, Hs-Full, Au-Full} — append-only with maximal propagation, coherence, history, and authority. No other system has this profile.
3.2 TikTok's recommendation algorithm (as a system component)
The recommendation engine specifically — not the full app, but the algorithm that selects what you see.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | Full | Videos, user profiles, engagement signals, model weights |
| Sh | 4 | Feature schemas, embedding structures, model architecture |
| Ac | Full | Vector similarity search, feature retrieval, candidate retrieval |
| Mt | 3 | Model updates, feature updates, engagement signal recording |
| Pg | 3 | Model deployment propagation, feature refresh |
| Ch | 2 | Eventual consistency on model versions across serving fleet |
| Pc | Full | Continuous perception — every swipe, watch time, share, pause is input |
| Pn | 0 | No direct presentation — feeds results to the app's presentation layer |
| Bn | 3 | Training ↔ serving ↔ feature store ↔ logging pipeline |
| Au | 2 | Internal service auth, data access controls |
| Hs | 3 | Full engagement history (drives the model), model versioning |
| Ev | Full | THIS IS THE CORE — the entire system IS evaluation. ML inference, feature computation, ranking, filtering |
Assessment: Ev at Full is the distinctive finding. The recommendation engine IS an evaluation system — it derives output (ranked video list) from input (user signals + content features + model weights). The model captures this correctly.
Does it break the model? No. But it stress-tests Evaluation (Ev) — this system exists PRIMARILY for Ev. All other primitives serve Ev. This is like how a ribosome EXISTS for evaluation — the recommendation engine is a purpose-built evaluator.
3.3 Arduino / Embedded firmware
A simple microcontroller running a control loop — read sensor, compute, actuate.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | 1 | Sensor readings, config values, state variables — in registers/RAM |
| Sh | 1 | C structs, bit fields — implicit shape, no dynamic schema |
| Ac | 1 | Direct memory address, register read — no query, no index |
| Mt | 2 | Direct register write, state variable update |
| Pg | 2 | Interrupt handlers, event loop — reactive but simple |
| Ch | 1 | Atomic operations, volatile variables — bare minimum |
| Pc | 3-4 | Continuous sensor input — temperature, light, motion, voltage |
| Pn | 2 | LED output, servo control, serial print — simple actuation |
| Bn | 1-2 | ISR boundary, maybe serial/I2C/SPI to other chips |
| Au | 0-1 | Maybe hardware write-protect, mostly none |
| Hs | 0 | No history — limited RAM, no storage |
| Ev | 1 | Simple formulas — convert ADC value to temperature, PID control loop |
Assessment: Low across most primitives but EVERYTHING APPLIES at some level. Even the simplest embedded system has content (sensor readings), mutation (register writes), perception (sensor input), and presentation (actuator output).
Pc at 3-4 is notably HIGH relative to everything else — embedded systems are perception-heavy. They exist to SENSE their environment. This is captured correctly.
Does it break the model? No. The primitives scale down to minimal systems. The positioning is informative: {Ct1, Ac1, Pc3-4, Pn2} = sensor-driven simple actuator. Distinctive and correct.
3.4 Compiler (GCC, LLVM)
A batch transformation system — takes source code in, produces machine code out.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | Full | AST nodes, IR, symbol tables, type info, machine instructions |
| Sh | Full | Language grammar, type system, IR type system |
| Ac | 3 | Symbol lookup, type resolution, scope walking |
| Mt | 3 | AST transformations, optimization passes, lowering |
| Pg | 2 | Pass pipeline — one pass's output feeds the next |
| Ch | 1 | Single-threaded mostly, parallel compilation units independent |
| Pc | 1 | Reads source files — batch input |
| Pn | 1 | Writes object files, prints errors/warnings — batch output |
| Bn | 2 | Frontend ↔ optimizer ↔ backend, separate compilation units |
| Au | 0-1 | File system permissions, no internal auth |
| Hs | 1 | No history of transformations (though debug info traces source) |
| Ev | Full | THIS IS THE CORE — parsing, type checking, optimization, code generation are ALL evaluation |
Assessment: Like the recommendation engine, a compiler is an EVALUATION SYSTEM. It exists to transform (evaluate) source code into machine code. Ev at Full is correct and distinctive.
Pc and Pn at 1 (batch) correctly capture that compilers aren't interactive (ignoring IDE integration which is a separate system).
Does it break the model? No. Correctly identifies compilers as evaluation-dominated systems with batch I/O.
3.5 Multiplayer VR game (VRChat, Rec Room)
Real-time 3D rendered social space with voice, avatars, physics, user-generated content.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | Full | 3D models, avatars, worlds, audio clips, physics objects |
| Sh | Full | Model formats, physics constraints, animation rigs, shader parameters |
| Ac | 3 | Spatial queries (what's near me), avatar lookup, world search |
| Mt | Full | Continuous — position updates 90fps, physics, voice, interactions |
| Pg | Full | Real-time state sync to all players, voice streaming, physics broadcast |
| Ch | 3-4 | Server-authoritative position, client prediction, rollback |
| Pc | Full | 6DOF head tracking, hand tracking, controller input, voice input, gaze direction |
| Pn | Full | Stereoscopic 3D rendering at 90fps, spatial audio, haptic feedback |
| Bn | 3-4 | Client ↔ game server ↔ voice server ↔ content CDN ↔ social services |
| Au | 3 | Accounts, friends, block, trust levels, instance permissions |
| Hs | 1 | Minimal — no replay, no undo (ephemeral experience) |
| Ev | 2-3 | Physics simulation, IK solving, shader evaluation, simple scripting |
Assessment: Everything at HIGH LEVELS except History. VR is the most demanding application type — it pushes Pc and Pn to their limits (full-body tracking input, stereoscopic 90fps output). The model captures this: {Pc-Full, Pn-Full, Mt-Full, Pg-Full} = maximum real-time interactivity.
Does it break the model? No. The distinction between VR and other interactive apps IS the Pc and Pn levels — VR requires Pc-Full (continuous multi-channel sensor input) and Pn-Full (continuous multi-channel immersive output). The model differentiates this correctly.
3.6 Unix pipes (cat file | grep pattern | sort | uniq -c)
A composition of simple programs connected by data streams. No persistence, no state, ephemeral.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | 1-2 | Text lines — structured only by convention (columns, separators) |
| Sh | 0-1 | No formal schema — convention only |
| Ac | 0-1 | Sequential read — no random access, no query |
| Mt | 0-1 | Each program reads input, writes output — no persistent mutation |
| Pg | 2 | Pipeline IS propagation — data flows through connected programs |
| Ch | 0 | No concurrency concerns — each program is sequential |
| Pc | 1 | Reads from stdin or file — batch |
| Pn | 1 | Writes to stdout or file — batch |
| Bn | 2 | Each program is a separate process connected by pipes |
| Au | 0-1 | Unix file permissions |
| Hs | 0 | Ephemeral — no history |
| Ev | 0-1 | Each program IS a fixed evaluator (grep, sort, uniq) but not user-defined |
Assessment: Almost everything at LOW LEVELS. But nothing at -1 or "doesn't apply." Even the simplest Unix pipeline has content (text), propagation (pipe flow), boundary (process separation), and perception/presentation (stdin/stdout).
The distinctive profile: {Pg2, Bn2, everything else ~0-1} = pure data flow with process boundaries. This IS the Unix philosophy structurally characterized.
Does it break the model? No. Scales down cleanly. The positioning is correct and informative.
3.7 Smart contract on Ethereum (a DeFi protocol like Uniswap)
Autonomous code running on a distributed virtual machine with economic value.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | 3 | Token balances, liquidity pools, price oracles, transaction history |
| Sh | 3 | Solidity structs, ABI schema, ERC-20/721 standards |
| Ac | 2 | Storage slot reads, event log queries, RPC calls |
| Mt | 2 | State-changing transactions — atomic, gas-metered |
| Pg | 3 | Events emitted on-chain, indexed by external services |
| Ch | Full | Blockchain consensus — global atomic state transitions |
| Pc | 2 | Receives transaction calls — event-driven, from wallets or other contracts |
| Pn | 0 | No presentation — frontend dApps provide UI separately |
| Bn | Full | Every contract is a boundary — isolated storage, typed interface (ABI) |
| Au | Full | Cryptographic — msg.sender, access modifiers, role patterns |
| Hs | Full | Blockchain IS history — every state change recorded permanently |
| Ev | 3-4 | Smart contract logic IS evaluation — AMM formulas, lending calculations, governance voting |
Assessment: Similar to Bitcoin but with HIGHER Ev (smart contracts are programmable evaluation). The DeFi protocol IS an evaluator — it computes prices, interest rates, liquidation thresholds.
Pn at 0 correctly captures that smart contracts have NO presentation — they're pure logic. Frontends are separate applications.
Does it break the model? No. Correctly differentiates from Bitcoin (higher Ev) and from traditional databases (higher Ch, Hs, Au).
3.8 Video surveillance system (CCTV + analytics)
Continuous video capture, recording, analysis, alerting.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | 3-4 | Video streams, frame metadata, detection events, faces, plates |
| Sh | 3 | Video format (H.264/265), metadata schema, detection types |
| Ac | 3 | Time-based search, detection-based search, spatial queries |
| Mt | 2 | Continuous append (recording), detection event creation |
| Pg | 3 | Alert notifications, detection event propagation to monitoring |
| Ch | 1-2 | Recordings don't need consistency — each camera independent |
| Pc | Full | CONTINUOUS video/audio input from multiple cameras — the core function |
| Pn | 3 | Live monitoring displays, recorded playback, alert dashboards |
| Bn | 3 | Cameras ↔ NVR ↔ analytics server ↔ monitoring station ↔ storage |
| Au | 3-4 | Camera access control, user roles, export permissions, legal compliance |
| Hs | Full | Recording IS history — the entire point is preserving visual history |
| Ev | 3-4 | Computer vision — face detection, motion detection, behavior analysis, plate recognition |
Assessment: Pc at Full is the DEFINING characteristic — this system exists to PERCEIVE continuously. Hs at Full because the system exists to RECORD. Ev at 3-4 because analytics IS evaluation.
Profile: {Pc-Full, Hs-Full, Ev3-4} = continuous perception with permanent history and computational analysis. This is distinctive and correct.
Does it break the model? No. Correctly captures the system's structure: perception-dominated with history and evaluation.
3.9 Operating system kernel (Linux)
The most fundamental software — manages hardware resources, provides abstractions, runs all other software.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | 2-3 | Processes, files, sockets, memory pages, device state |
| Sh | 3 | File types, socket types, ioctl structures, proc/sys interfaces |
| Ac | 3 | File paths, process IDs, file descriptors — multiple access mechanisms |
| Mt | Full | System calls — every state change in the system goes through the kernel |
| Pg | Full | Signals, polling, epoll, inotify, netlink — rich event propagation |
| Ch | Full | Locks, mutexes, RCU, atomic operations, transaction-like filesystems |
| Pc | Full | Interrupts from hardware, system calls from userspace — continuous input from multiple sources |
| Pn | 2 | Terminal output, framebuffer, audio devices — kernel provides but doesn't manage presentation directly |
| Bn | Full | Process isolation, namespaces, cgroups, seccomp, network namespaces |
| Au | Full | Users, groups, capabilities, SELinux/AppArmor, seccomp |
| Hs | 2 | Journaling filesystems, audit log, dmesg — but not application-level version control |
| Ev | 3 | BPF programs, iptables rules, scheduling algorithms, filesystem logic |
Assessment: Almost everything at HIGH levels. The kernel IS infrastructure — it provides high levels of every primitive for applications running on top. Pn at 2 (kernel doesn't manage presentation directly — it provides the framebuffer but display servers handle the rest) is correct and distinguishing.
Profile: Most things at 3-Full, with Pn at 2 and Hs at 2. The kernel is a PLATFORM — high capability across the board.
Does it break the model? No. But it raises an interesting question: is the kernel an APPLICATION or INFRASTRUCTURE? It maps to the app architecture lattice, but it might be better understood as part of the digital computing substrate or as bridge machinery between hardware and applications.
The fact that it CAN be positioned in the app architecture lattice suggests the lattice is general enough to capture infrastructure too. The kernel at high levels on most primitives IS what makes it infrastructure — it provides capability that applications inherit.
3.10 A static website (plain HTML + CSS, no JavaScript)
The simplest possible "application" — just files served by a web server.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | 2 | HTML pages, CSS, images — structured but fixed |
| Sh | 2 | HTML structure, CSS classes — implicit schema |
| Ac | 1 | URL paths — direct address only, no search |
| Mt | 0 | NO MUTATION — content is static |
| Pg | 0 | NO PROPAGATION — nothing changes |
| Ch | 0 | NO COHERENCE — nothing concurrent |
| Pc | 1 | HTTP requests — minimal, batch-like (request/response) |
| Pn | 2-3 | HTML rendered by browser — static but visual |
| Bn | 2 | Client ↔ web server |
| Au | 0-1 | Maybe HTTP basic auth, usually none |
| Hs | 0 | No history (unless you count the web server access log) |
| Ev | 0 | No computation — pure static content |
Assessment: Nearly everything at 0-2. But it IS positioned — a static website is a valid (minimal) application. Profile: {Ct2, Pn2-3, everything else ~0} = static content presentation. This IS what a static website is — content that's presented but doesn't change, isn't queried, isn't interactive.
Does it break the model? No. The model correctly identifies static websites as minimal applications — they have content and presentation but almost nothing else. The positioning is informative: compare to Gmail (high everything) or Postgres (high internal, low external) or Arduino (high Pc, low everything else).
3.11 AI coding assistant (Cursor, Claude Code)
An agent that reads code, understands context, generates/edits code, uses tools, takes direction.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | Full | Source code, conversation history, file system state, tool outputs |
| Sh | 3-4 | Language grammars, AST structures, file types, prompt schemas |
| Ac | Full | Code search (grep, glob), file reading, symbol lookup, web search |
| Mt | 3-4 | File edits, code generation, git operations, terminal commands |
| Pg | 2-3 | File change notifications, tool result streaming |
| Ch | 2 | Single-agent usually — limited concurrency |
| Pc | Full | User prompts, file system state, tool outputs, lint/compile errors — CONTINUOUS multi-source |
| Pn | 3-4 | Streaming text output, code diffs, tool call display, status updates |
| Bn | 3 | Agent ↔ LLM API ↔ tools ↔ file system ↔ terminal ↔ web |
| Au | 2-3 | Sandbox permissions, tool approval, file access scoping |
| Hs | 3 | Conversation history, git for code changes |
| Ev | Full | LLM inference IS evaluation — token generation, tool selection, planning |
Assessment: Ev at Full — the AI IS an evaluator. The system exists to evaluate (generate, reason, plan). Pc at Full — the agent perceives multiple input channels continuously (user messages, file state, tool outputs, errors).
This is an AGENT — it actively perceives, evaluates, and acts. The profile {Pc-Full, Ev-Full, Mt3-4, Pn3-4} = active perceiver-evaluator that modifies the world. This is structurally different from passive tools (which have low Pc/Ev) or pure databases (which have low Pc/Pn).
Does it break the model? No. The model correctly characterizes AI agents as evaluation-dominated active perceivers. This is the kind of system where Evaluation as a surface primitive proves its worth — without Ev, you can't distinguish an AI coding assistant from a text editor structurally.
3.12 Digital twin / simulation (factory model, climate model)
A computational model that mirrors a physical system and runs simulations.
| Primitive | Level | What it looks like |
|---|---|---|
| Ct | Full | Physical system model — components, properties, relationships, time series |
| Sh | Full | Simulation schema — component types, physics equations, constraint definitions |
| Ac | 3-4 | Query simulation state, search parameter space, retrieve time series |
| Mt | 3 | Update model parameters, inject disturbances, advance simulation time |
| Pg | 3 | State changes propagate through model — physics simulation IS propagation |
| Ch | 2 | Single simulation thread usually, parallel ensembles independent |
| Pc | 3-4 | Receives sensor data from physical twin, user parameter adjustments |
| Pn | 3-4 | 3D visualization, dashboard, time series plots, alerts |
| Bn | 3 | Simulation ↔ visualization ↔ data acquisition ↔ control system |
| Au | 2 | User roles, data source authentication |
| Hs | 3-4 | Simulation run history, parameter sweep records, scenario comparisons |
| Ev | Full | THIS IS THE CORE — the entire system IS evaluation (physics simulation, what-if analysis) |
Assessment: Another Ev-Full system. Digital twins exist to EVALUATE — to simulate what the physical system does or would do. Pc at 3-4 captures the sensor data input from the physical twin. Pn at 3-4 captures the visualization output.
Does it break the model? No. Correctly identifies simulation as evaluation-dominated with real-time perception (sensor feeds) and rich presentation (visualization).
3. Patterns across exotic cases
3.1 Systems that exist FOR evaluation
| System | Ev level | What it evaluates |
|---|---|---|
| TikTok recommendation | Full | User preference → ranked content |
| Compiler | Full | Source code → machine code |
| AI coding assistant | Full | Context → generated code |
| Digital twin | Full | Physical model → simulated behavior |
| Smart contract | 3-4 | Economic rules → token transfers |
| Surveillance analytics | 3-4 | Video → detection events |
| Postgres (materialized views) | 3 | Queries → derived data |
A significant fraction of software exists PRIMARILY for evaluation. The Evaluation primitive captures this correctly — without it, these systems are indistinguishable from storage systems.
3.2 The Pc-Pn profile as system characterizer
| System type | Pc | Pn | Character |
|---|---|---|---|
| Backend database | 1 | 0 | Data service — no human interaction |
| Batch processor | 1 | 1 | Transforms files — minimal I/O |
| API service | 2 | 2 | Request/response — structured I/O |
| Web application | 3 | 3 | Interactive — human in the loop |
| Game / VR | Full | Full | Immersive — continuous multi-channel |
| Embedded sensor | 3-4 | 2 | Perception-dominated — senses more than it shows |
| Surveillance | Full | 3 | Perception-first — records everything |
The Pc-Pn position IS a fundamental classifier of software. It separates backend from frontend, batch from interactive, passive from immersive. This validates Perception and Presentation as primitives — they carry structural information that no other primitive provides.
3.3 Nothing broke the model
Across all 12 case studies (4 standard + 8 exotic):
- Every primitive applied at SOME level (even if 0) to every system
- No system had a structural concern NOT captured by the 12 primitives
- The positions were INFORMATIVE — they distinguished systems in ways that matched real structural differences
- The conditional primitives (Hs, Ev) ranged from 0 to Full across systems — confirming they're real axes of variation
3.4 The closest to breaking
The OS kernel raised the question of whether infrastructure should be positioned in the same lattice as applications. It can be — the kernel at high levels on most primitives IS what makes it infrastructure. But it might also be understood as part of the digital computing substrate or as bridge machinery. The lattice handles it either way.
Unix pipes tested the lower bound — can the simplest software be positioned? Yes. Even a pipeline of trivial programs has positions on all 12 axes.
4. Assessment
4.1 Coverage
All 12 primitives have demonstrated utility across the case studies. No primitive was useless for any system. The conditional primitives (Hs, Ev) showed full range (0 to Full) — they're real axes, just not universal.
4.2 Distinctiveness
Every system has a distinctive 12-dimensional profile. No two systems share the same position. The positions correctly capture what makes each system structurally different:
- Blockchain: {Mt1, Ch-Full, Hs-Full, Au-Full} — append-only consensus with permanent history
- VR: {Pc-Full, Pn-Full, Mt-Full, Pg-Full} — maximum real-time interactivity
- Arduino: {Pc3-4, everything else low} — sensor-dominated minimal system
- Compiler: {Ev-Full, Pc1, Pn1} — pure batch evaluation
4.3 Structural predictions
The positions generate testable predictions:
- Systems with high Pg but low Ch will have consistency issues under load (true for many real-time systems)
- Systems with high Ev but low Hs can't reproduce their evaluations (true for non-deterministic ML systems)
- Systems with high Pc but low Pn are monitoring/recording systems (true for surveillance, logging)
- Systems with high Pn but low Pc are broadcast systems (true for static websites, kiosks)
4.4 What WASN'T tested
- Hardware description languages (Verilog, VHDL) — software that describes hardware
- Biological sequence analysis tools — software operating on biological data
- Music production (DAW) — temporal + creative
- Spreadsheets — the canonical Evaluation system
- Operating system's GUI (window manager, compositor) — the presentation infrastructure
These would be good additional case studies but the current set covers the structural space well enough to validate the 12-primitive model.
5. Conclusion
The 12-primitive model {Ct, Sh, Ac, Mt, Pg, Ch, Pc, Pn, Bn, Au, Hs, Ev} survives the exotic case study review. Every primitive applies to every system at some level. Positions are distinctive and informative. The model correctly captures what makes blockchain different from VR different from a compiler different from a thermostat.
The strongest validations:
- Perception (Pc) and Presentation (Pn) differentiate interactive from non-interactive systems — confirmed by the Pc-Pn profile being a fundamental system classifier
- Evaluation (Ev) differentiates computation-dominated from data-dominated systems — confirmed by compilers, ML systems, simulations, and smart contracts all being Ev-Full
- History (Hs) ranges from 0 (Arduino, static sites) to Full (blockchain, Git, surveillance) — a genuine axis of variation, not universal but structurally important