1. Scope and Purpose

This document develops a framework for understanding computational systems and the emergence of platforms from first principles.

Goals:

Descriptive: Provide vocabulary to analyze existing systems, identify platform boundaries, and characterize their components.
Predictive: Enable assessment of whether a collection of systems would benefit from platform formation, and where platform boundaries would most naturally emerge.

Method: The framework proceeds from definitions (stipulated meanings) through axioms (foundational claims taken as given) to theorems (claims derivable from axioms) to hypotheses (predictive claims that extend beyond strict derivation).

Structure: The framework is organized in two parts:

Part I (Core Framework): Addresses computational systems in general, independent of what consumes their interfaces (other systems or humans)
Part II (Human-Facing Extension): Extends the core framework for systems whose consumers are human users, introducing cognitive constraints and human-specific requirements

Part II is a proper superset of Part I — all core framework elements apply to human-facing systems, with additional constraints and properties layered on top.

2. Limits

This framework addresses the structural and functional properties of computational systems. It does not address:

Economic forces, incentives, or market dynamics
Human factors beyond cognitive constraints relevant to interface design
Organizational behavior or social systems
Historical contingency or path dependence
Legal, regulatory, or policy constraints

These factors influence real systems but are outside the scope of this structural analysis.

Part I: Core Framework

3. Definitions

Foundational Concepts

Def 3.1Data. A representation of information in a form that can be stored, transmitted, or transformed.

Def 3.2State. Data that persists within a system across transformations and that may affect future transformations.

Def 3.3Transformation. An operation that takes input data and produces output data according to defined rules.

Def 3.4Computation. The execution of one or more transformations. Computation consumes resources (time, energy) and occurs at a specific locus.

Def 3.5Locus (pl. Loci). A location where computation or persistence occurs. Loci have physical properties (capacity, speed, energy consumption) and exist in topological relationship to other loci, characterized by the communication properties between them.

Def 3.6Topology. The arrangement of loci and the connections between them. Topology determines which loci can communicate directly, through what medium, and with what properties (bandwidth, latency, reliability).

Def 3.7Persistence. The maintenance of data across time at a locus. Persistence has:

Duration: How long data is maintained
Durability: The probability that data survives for the intended duration
Tier: Position in the persistence hierarchy, characterized by tradeoffs between access speed, capacity, cost, and durability

Def 3.8Transport. The movement of data from one locus to another. Transport consumes resources and has properties including:

Latency: Time to initiate and complete transfer
Bandwidth: Data volume per unit time
Reliability: Probability of successful delivery

System Concepts

Def 3.9Interface. The specification of how a system exchanges data with external entities. An interface defines:

Input interface: What data the system accepts and in what form
Output interface: What data the system produces and in what form
Behavioral contract: What operations are available, what guarantees the system provides, what ordering constraints apply, and what error conditions may occur

Def 3.10System. A bounded entity that performs computation, characterized by:

Its interface (how it interacts with the external world)
Its internal computation (how it transforms inputs to outputs)
Its internal state (data that persists across invocations)

Def 3.11System Boundary. The demarcation between a system's internal structure and its external interface. What is inside the boundary is implementation; what is at the boundary is interface; what is outside the boundary is environment.

Def 3.12Subsystem. A system that exists within the boundary of another system. The containing system is called the parent system.

Def 3.13Composition. The combination of multiple systems to form a new system, where the composed system's interface may differ from the interfaces of its components. Composition occurs when one system's output interface connects to another system's input interface.

Abstraction Concepts

Def 3.14Abstraction. The process of defining an interface that hides implementation details. An abstraction exposes selected properties of a system while concealing others. Abstraction necessarily involves information loss about the underlying implementation.

Def 3.15Abstraction Layer. A system or set of systems that provides a common interface over heterogeneous subsystems, enabling other systems to interact with the subsystems without knowledge of their specific implementations.

Def 3.16Platform. An abstraction layer that provides standardized interfaces, shared services, and coordination mechanisms for a collection of systems, reducing the complexity that each system must independently manage.

Task and Self-Sufficiency Concepts

Def 3.17Task Loop. A complete cycle of:

Input acquisition (receiving data or intent from an external agent)
Processing (transforming data toward a goal)
Output presentation (making results available to the external agent)
State persistence (maintaining context for future cycles)
Feedback (enabling the next input to be informed by the output)

A task loop represents a unit of purposeful work completed for an agent (whether another system or a human user).

Def 3.18Self-Sufficiency. A system is self-sufficient with respect to a task loop if it can complete the full loop using only internal resources, without requiring external systems. Self-sufficiency may be:

Full: No external dependencies for the task loop
Time-limited: Can complete the task loop for limited duration (e.g., finite power or consumable resources)
Degraded: Can complete a reduced version of the task loop without external resources
Dependent: Cannot complete the task loop without external resources

Def 3.19Platform Completeness. The degree to which a platform can support self-sufficient task loops across its intended domain of use. A more complete platform supports a larger fraction of its intended tasks self-sufficiently.

Def 3.20Self-Sufficiency Boundary. The boundary that encloses all components required for a system to complete its characteristic task loops without external dependencies. This boundary corresponds to a natural unit of the system.

Measurement Concepts

Def 3.21Complexity. The amount of information required to fully describe a system's behavior. Complexity increases with:

The number of distinct states
The number of possible interactions
The number of failure modes
The depth of conditional logic

Def 3.22Performance. The measurable efficiency of computation, persistence, or transport. Key metrics include throughput, latency, capacity, energy efficiency, and reliability.

4. Axioms

Foundation Axioms

A1Physical Substrate. All computation, persistence, and transport require a physical substrate and consume energy. The properties of the substrate constrain what is possible.

A2Heterogeneity of Devices. The devices that perform computation, persistence, and transport are heterogeneous in their capabilities, costs, and constraints.

A3Heterogeneity of Data. Data varies in structure, size, semantics, temporal characteristics, and quality.

A4Heterogeneity of Transformations. The transformations that can be applied to data are heterogeneous in their computational requirements, complexity, and resource consumption.

A5Finite Resources. Time, energy, storage capacity, and bandwidth are finite. Every computation, persistence, and transport operation consumes resources from finite pools.

Performance Axioms

A6Measurable Performance. The performance of computation, persistence, and transport can be observed, measured, and compared.

A7Performance Tradeoffs. Performance in one dimension often comes at the cost of performance in another dimension. Common tradeoffs include:

Speed vs. energy consumption
Capacity vs. access speed
Throughput vs. latency
Generality vs. efficiency
Self-sufficiency vs. specialized capability

A8Specialization Advantage. For any given task, a specialized implementation can outperform a general-purpose implementation on the metrics most relevant to that task, at the cost of reduced applicability to other tasks.

Concurrency Axioms

A9Concurrency. Multiple computations can execute simultaneously across different loci.

A10Shared Data Conflict. When multiple concurrent computations access the same data and at least one modifies it, the outcome is undefined without explicit coordination.

Interaction Axioms

A11Data Sharing Requirement. For data to be shared between systems, the systems must agree on data representation, meaning, and exchange protocol.

A12No Implicit Trust. No property of an external system (correctness, reliability, security, performance) can be assumed without verification or guarantee.

A13Interface as Boundary. A system can only interact with another system through that system's defined interface. Internal implementation is not directly accessible.

Reliability Axioms

A14Universal Fallibility. All physical devices can fail. Failure may be total (complete cessation of function), partial (degraded function), or Byzantine (incorrect function that may appear correct).

A15Degradation. Physical devices degrade over time. Performance characteristics change, and probability of failure increases with age and use.

A16Error Propagation. Errors in one system can propagate to other systems that depend on it. Without explicit error handling, errors tend to cascade.

Self-Sufficiency Axioms

A17Task Loop Closure Requirement. For a system to provide standalone value to an external agent, it must close at least one task loop relevant to that agent. Systems that cannot close any task loop for their intended consumers are necessarily components of larger systems, not standalone systems.

A18Self-Sufficiency Hierarchy. Self-sufficiency is nested. A self-sufficient system contains subsystems that are not individually self-sufficient. The property of self-sufficiency emerges at specific integration points where task loop closure becomes possible.

Network effects axioms

A19Path Dependence. Coordination costs increase with the number of systems dependent on an interface. Once systems depend on an interface, the cost of changing that interface includes the coordination cost with all dependent systems. This creates lock-in proportional to dependency depth.

5. Theorems

Theorems on Specialization

T1Specialization Emergence. Given A2 (heterogeneity of devices) and A8 (specialization advantage), devices and systems will specialize to achieve higher performance on specific tasks.

T2Specialization Tradeoff. Given A7 (performance tradeoffs) and T1, increased specialization yields improved performance on target tasks at the cost of decreased applicability to non-target tasks. Systems must balance specialization against flexibility based on their expected workload.

Theorems on Composition

T3Composition Enables Complexity. Given Def 3.13 (composition) and Def 3.14 (abstraction), systems can be composed to perform functions more complex than any individual component, with the composed system's interface hiding internal complexity.

T4Composition Cost. Composition introduces overhead: the cost of coordination between subsystems, the cost of data transformation at interfaces, and the cost of managing the composition itself. Composition is beneficial only when the value of the combined function exceeds this overhead.

T5Recursive Composition. Given T3, composed systems can themselves be composed, enabling arbitrary depth of system hierarchy. Each level of composition adds both capability and overhead.

Theorems on Concurrency

T6Coordination Necessity. Given A9 (concurrency) and A10 (shared data conflict), systems that share data and operate concurrently require coordination mechanisms to ensure consistent outcomes.

T7Coordination Cost. Coordination mechanisms consume resources and constrain parallelism. Stronger consistency guarantees require more costly coordination.

T8Concurrency-Consistency Tradeoff. Given T6 and T7, systems must trade off between the degree of concurrency (and thus potential parallelism) and the strength of consistency guarantees.

Theorems on Inter-System Communication

T9Communication Requirements. Given A11 (data sharing requirement) and A12 (no implicit trust), communication between systems requires:

Agreement on representation: A shared data format or translation mechanism
Agreement on protocol: Rules for initiating, conducting, and terminating exchange
Trust establishment: Mechanisms to verify or guarantee relevant properties of the communicating parties
Error handling: Mechanisms to detect, report, and recover from communication failures

T10Communication Overhead. Each requirement in T9 adds complexity and resource consumption to inter-system communication. The overhead increases with the number of communicating systems and the heterogeneity of their interfaces.

Theorems on Reliability

T11Reliability Requires Redundancy. Given A14 (universal fallibility), achieving reliability greater than that of any individual component requires redundancy—multiple components such that the failure of any single component does not cause system failure.

T12Reliability Cost. Redundancy consumes additional resources (hardware, energy, complexity). Higher reliability requires greater redundancy and thus greater cost.

T13Error Handling Burden. Given A16 (error propagation), every system must either handle errors from systems it depends on, propagate errors to systems that depend on it, or accept undefined behavior on error. Comprehensive error handling is complex and resource-consuming.

Theorems on Scale Effects

T14Coordination Explosion. Given T10 (communication overhead), as the number of systems increases, the potential number of inter-system relationships grows combinatorially. Without structural intervention, coordination overhead eventually dominates system resources.

T15Heterogeneity Burden. Given A2, A3, A4 (heterogeneity axioms) and T9 (communication requirements), as the number of distinct system types increases, the number of distinct interface adaptations required for full interoperability grows multiplicatively.

T16Standard Emergence. Given T14 and T15, collections of interoperating systems experience pressure toward standardized interfaces and data representations. Standardization reduces per-system coordination burden by allowing systems to implement one standard interface rather than numerous pairwise adaptations.

Theorems on Abstraction

T17Abstraction Tradeoff. Given Def 3.14 (abstraction), every abstraction trades off information hiding (reducing what systems must know about each other) against expressiveness (the ability to leverage specific capabilities of underlying systems). An abstraction that hides everything is unusable; one that hides nothing provides no benefit.

T18Abstraction Layer Value. Given T14, T15, and T17, an abstraction layer that provides a common interface over heterogeneous subsystems reduces total system complexity if and only if the complexity saved by the common interface exceeds the complexity of the abstraction layer itself plus the expressiveness lost.

T19Leaky Abstraction. Given A1 (physical substrate) and Def 3.14 (abstraction), no abstraction over physical systems can be complete. Properties of underlying systems inevitably affect behavior in ways not fully captured by the abstract interface.

Theorems on Self-Sufficiency

T20Self-Sufficiency Boundary as Natural Platform Boundary. Given H1 (platform formation) and A17 (task loop closure requirement), self-sufficiency boundaries correspond to natural platform boundaries. The point at which a system becomes self-sufficient for its intended consumers is a point of maximum complexity reduction benefit—subsystems below this point cannot provide standalone value and are naturally hidden.

T21Self-Sufficiency Integration Requirements. Given Def 3.17 (task loop) and A17 (task loop closure requirement), achieving self-sufficiency for a given task domain requires integrating:

Input acquisition capability for that domain
Processing capability sufficient for domain tasks
Output presentation capability for that domain
Persistence capability sufficient for task continuity
Power/resource autonomy sufficient for task completion

T22Self-Sufficiency and Trust Simplification. Given A12 (no implicit trust) and Def 3.20 (self-sufficiency boundary), components within a self-sufficiency boundary can trust each other with reduced verification overhead compared to cross-boundary trust. The self-sufficiency boundary often corresponds to a physical security boundary, ownership boundary, and trust domain boundary simultaneously.

T23Self-Sufficiency vs. Capability Tradeoff. Given A8 (specialization advantage) and Def 3.19 (platform completeness), there is a tradeoff between self-sufficiency and specialized capability. A self-sufficient system must include all components for task loop closure, which may prevent optimization for specific tasks. A dependent system can externalize components, potentially achieving higher capability at the cost of self-sufficiency.

Theorems on network effects

T24Standards Capture. Early participants in standard formation have outsized influence on interface characteristics. Standards tend to reflect the interests and capabilities of early participants even when later participants are more numerous.

6. Hypotheses

H1. Platform Formation

Given T14 (coordination explosion), T15 (heterogeneity burden), T16 (standard emergence), and T18 (abstraction layer value):

Platform boundaries form at points in the system architecture where the net complexity reduction from introducing an abstraction layer is maximized.

More precisely, a platform boundary will form where:

Multiple systems require similar services (coordination, resource management, communication)
The cost of each system independently implementing these services exceeds the cost of a shared implementation
A stable interface can be defined that serves the common needs without excessively constraining the systems

H2. Multiple Platform Layers

Given T5 (recursive composition) and H1:

Systems of sufficient complexity exhibit multiple platform boundaries at different levels of abstraction. The number and location of platform layers is determined by the distribution of complexity in the system—each point where many components require similar services is a candidate for platform formation.

H3. Platform Services

Platforms characteristically provide some or all of the following services, corresponding to the communication requirements of T9 and the scale effects of T14-T16:

Resource abstraction: Uniform interface over heterogeneous underlying resources
Resource management: Allocation, scheduling, and arbitration of shared resources
Communication facilitation: Standard protocols, message routing, format translation
Coordination services: Synchronization, transaction management, consensus mechanisms
Trust infrastructure: Identity verification, authentication, authorization, audit
Reliability services: Redundancy management, failover, error recovery
Discovery and metadata: Registration, capability advertisement, system introspection

H4. Platform Evolution

Given A15 (degradation), T19 (leaky abstraction), and the dynamics of system change over time:

Platforms evolve toward increased stability of interface and increased flexibility of implementation. Once systems depend on a platform interface, changing that interface imposes costs on all dependent systems, creating pressure to maintain compatibility. Meanwhile, improvements in underlying technology create pressure to update implementations. The result is interface ossification paired with implementation change.

H5. Specialization Migration

Given T1 (specialization emergence), T2 (specialization tradeoff), and technological change:

Functions migrate between abstraction layers over time. Functions that begin in upper layers (as software, as platform services) migrate to lower layers (as hardware, as fundamental primitives) when they become common enough that specialization advantage outweighs flexibility loss. Functions may also migrate upward when flexibility becomes more valuable than performance.

H6. Self-Sufficiency Stability

Given T20 (self-sufficiency boundary as natural platform boundary) and T22 (self-sufficiency and trust simplification):

Self-sufficiency boundaries exhibit stability because they simultaneously satisfy multiple constraints:

Natural units of ownership and control
Trust domain boundaries
Physical packaging boundaries (often)
Failure isolation boundaries
Resource accounting boundaries

Changes to self-sufficiency boundaries require overcoming the stability provided by all these aligned boundaries, which explains why such transitions are slow and often incomplete.

7. Framework Application Method (Core)

To apply the core framework to an existing or proposed system:

Analysis Steps

Identify systems and boundaries: What are the distinct systems? Where are the interfaces between them?
Characterize heterogeneity: What variation exists in devices (A2), data (A3), and transformations (A4)?
Map communication patterns: Which systems communicate? What do T9's requirements (representation, protocol, trust, error handling) look like for each relationship?
Assess coordination needs: Where does concurrency (A9) create potential for conflict (A10)? What coordination mechanisms exist?
Evaluate reliability structure: Where are single points of failure? What redundancy exists? How are errors handled?
Identify abstraction layers: What platforms or platform-like structures exist? What services do they provide (per H3)?
Assess platform boundaries: Do the existing platform boundaries correspond to complexity peaks (H1)? Are there missing platform layers where T14/T15 effects suggest one should exist?
Identify self-sufficiency boundaries: Which systems are self-sufficient for their intended task loops? Do self-sufficiency boundaries align with platform boundaries (T20)?
Evaluate completeness: For each identified platform, what fraction of its intended task domain can it serve self-sufficiently (Def 3.19)?

Predictive Questions

Using the framework to predict:

Should a platform exist here? Apply H1: Is there a collection of systems with common needs where shared implementation would cost less than independent implementation?
What services should a platform provide? Apply H3: Which of the characteristic platform services address the specific coordination, communication, and reliability needs present?
Where will the system evolve? Apply H4 and H5: What interfaces are under pressure to stabilize? What functions are candidates for migration between layers?
Is this self-sufficiency boundary stable? Apply H6: Does the boundary align with ownership, trust, physical packaging, and failure isolation boundaries?

Part II: Human-Facing Systems Extension

This part extends the core framework for systems whose intended consumers are human users. All definitions, axioms, theorems, and hypotheses from Part I apply; this part adds human-specific elements.

8. Human-Facing Definitions

Def 8.1Human Interface. An interface designed for interaction with human users, characterized by constraints derived from human cognition, perception, and behavior rather than computational limits alone.

Def 8.2Mental Model. A simplified internal representation that a human user constructs to understand and predict system behavior. Mental models are necessarily incomplete and may be inaccurate.

Def 8.3Actionability. The degree to which a system state or event can be meaningfully affected by user action. High actionability implies the user has both the capability and the knowledge to respond effectively.

Def 8.4Visibility. The degree to which a system state, event, or property is exposed to human users through the interface. Visibility exists on a spectrum from fully hidden to fully exposed.

Def 8.5Human Task Loop. A task loop (Def 3.17) where the external agent is a human user. Human task loops are characterized by:

Input through human-compatible modalities (visual, motor, auditory, tactile)
Output through human-perceivable modalities (visual, auditory, haptic)
Time scales compatible with human perception and cognition
State persistence aligned with human task boundaries (sessions, documents, projects)

Def 8.6Human-Facing Platform. A platform (Def 3.16) whose consumers include human users directly, not only other systems. Human-facing platforms must satisfy human interface constraints in addition to computational interface requirements.

9. Human-Facing Axioms

HA1Cognitive Constraints. Human users have fixed cognitive limits including:

Attention capacity (limited simultaneous focus)
Working memory size (limited items held active)
Learning rate (limited speed of skill acquisition)
Perceptual thresholds (minimum detectable differences, response time expectations)

These limits constrain the complexity of interfaces that humans can effectively use.

HA2Goal-Directed Users. Human users interact with platforms instrumentally, to achieve goals that exist outside the platform. The platform's value to users derives from its support for user goals, not from the platform's internal properties.

HA3Interpretation Variance. Different human users will interpret the same interface differently based on prior knowledge, expectations, and context. No interface has a single "correct" interpretation across all users.

HA4Physical Irreducibility. No abstraction can fully hide physical constraints that require human response. Physical realities (power, connectivity, hardware integrity, environmental conditions) propagate through all abstraction layers to human visibility when they demand human action.

10. Human-Facing Theorems

Theorems on Visibility and Actionability

HT1Visibility-Actionability Correspondence. Given HA1 (cognitive constraints) and finite user attention, platforms should expose to users those states and events that have high actionability and hide those with low actionability. Violations of this principle—hiding actionable information or exposing non-actionable information—reduce platform effectiveness.

HT2Physical Leakage. Given HA4 (physical irreducibility) and A1 (physical substrate), certain physical facts propagate to human visibility regardless of abstraction depth:

Power availability
Physical connectivity
Hardware failure
Environmental constraints (temperature, damage)
Physical security

These constitute an irreducible physical interface that all human-facing platforms must accommodate.

Theorems on Mental Models

HT3Mental Model Support. Given HA2 (goal-directed users) and Def 8.2 (mental models), effective human-facing platforms support the formation of accurate mental models through:

Consistent behavior across similar operations
Predictable responses to user actions
Visible system state that maps to user-relevant concepts
Feedback that confirms or corrects user expectations

HT4Mental Model Limits. Given HA1 (cognitive constraints) and HA3 (interpretation variance), mental models are necessarily simplified and vary across users. Platforms cannot assume users have complete or accurate models, and must function reasonably even when user models are incomplete or incorrect.

Theorems on Self-Sufficiency for Humans

HT5Human Self-Sufficiency Requirements. Given Def 8.5 (human task loop) and T21 (self-sufficiency integration requirements), a platform that is self-sufficient for human use must integrate:

Human input capability (keyboard, mouse, touch, voice, gesture)
Processing capability sufficient for human-relevant tasks
Human output capability (display, audio, haptic feedback)
Persistence capability sufficient for human task continuity
Power autonomy sufficient for task session completion

HT6Self-Sufficiency and Mental Models. Given HT3 (mental model support) and Def 3.20 (self-sufficiency boundary), self-sufficient systems map naturally to user mental models because they correspond to coherent objects with clear boundaries and independent existence. Non-self-sufficient systems are harder for users to conceptualize and require understanding of external dependencies that may be invisible.

Theorems on Human Interface Design

HT7Error Communication Transformation. Given T13 (error handling burden) and HA1 (cognitive constraints), errors surfaced to human users must be transformed from technical form (error codes, stack traces, system state) to human-comprehensible form including:

Explanation in terms of user goals, not system internals
Actionable guidance appropriate to user capability
Appropriate severity indication
Recovery paths when possible

HT8Human Time Scale Alignment. Given HA1 (cognitive constraints) and Def 8.5 (human task loop), human-facing platforms must align their response characteristics with human perceptual thresholds:

Immediate feedback (< 100ms) for direct manipulation
Progress indication for operations exceeding ~1 second
Interruptibility for operations exceeding ~10 seconds
Session persistence for tasks spanning hours or days

HT9Differentiated Trust. Given A12 (no implicit trust) and HA2 (goal-directed users), trust in human-facing systems operates on two levels:

Technical trust: Verifiable properties established through cryptographic or mechanical means
Psychological trust: User confidence based on experience, reputation, design, and social proof

Human-facing platforms must satisfy both; technical trust without psychological trust leads to user rejection, while psychological trust without technical trust leads to security failures.

11. Human-Facing Hypotheses

HH1. Human Interaction Point

Given H1 (platform formation), T20 (self-sufficiency boundary as natural platform boundary), and HA1 (cognitive constraints):

Human users preferentially interface with platforms at the lowest level that achieves self-sufficiency for human task loops while remaining within human complexity tolerance.

Systems below this level are perceived as "components" or remain invisible. Systems at this level are perceived as "devices" or "products."

HH2. Interface Point Determination

Given HH1 and the historical trajectory of computing:

The platform layer at which humans interface is determined by the balance between:

User complexity tolerance (how much the user can and will manage)
Required capability (what the user needs to accomplish)
Self-sufficiency achievability (whether task loops can close at this level)
Connectivity reliability (whether external dependencies can be assumed)

Different user populations, task domains, and technological contexts will produce different interface points.

HH3. Visibility Gradient

Given HT1 (visibility-actionability correspondence) and HT2 (physical leakage):

Platforms exhibit a visibility gradient where:

Highly actionable states are exposed (user can and should respond)
Low-actionability implementation details are hidden (user cannot meaningfully respond)
Physical constraints that require human response remain visible regardless of abstraction depth
The gradient aligns with the abstraction layer hierarchy, with lower layers progressively hidden

HH4. Self-Sufficient Platforms as Stable Interaction Points

Given H6 (self-sufficiency stability) and HT6 (self-sufficiency and mental models):

Self-sufficient platforms exhibit stability as human interaction points because they satisfy multiple constraints simultaneously:

Task loop closure (functional completeness)
Mental model coherence (conceptual clarity)
Ownership clarity (control and responsibility boundaries)
Trust domain alignment (security and privacy boundaries)
Physical boundary alignment (often correspond to physical objects)

Shifts in human interface points (e.g., from PC to cloud) require overcoming stability on all these dimensions, explaining why such shifts are gradual and often incomplete.

HH5. Platform Differentiation by Consumer Type

Given the distinct requirements of machine consumers (Part I) and human consumers (Part II):

Systems with both human and machine consumers develop differentiated characteristics:

Lower layers optimize for machine-to-machine interaction (technical precision, performance, minimal abstraction overhead)
Upper layers optimize for human interaction (cognitive fit, learnability, appropriate abstraction level, error recovery)
The transition between these regimes constitutes a qualitatively distinct platform boundary

This boundary often corresponds to the self-sufficiency boundary for human task loops.

12. Framework Application Method (Human-Facing Extension)

When analyzing human-facing systems, apply the core framework method (Section 7) plus:

Additional Analysis Steps

Identify the human interface point: At what platform layer do human users interact? Does this align with self-sufficiency boundaries (HH1)?
Map the visibility gradient: What is exposed to users vs. hidden? Does visibility correlate with actionability (HT1)?
Assess physical leakage: What physical realities propagate to user visibility (HT2)? Are these appropriately surfaced?
Evaluate mental model support: Does the platform support formation of accurate mental models (HT3)? What models do users likely form?
Check time scale alignment: Do platform responses align with human perceptual thresholds (HT8)?
Assess error handling for humans: Are errors transformed appropriately for human consumption (HT7)?
Evaluate trust on both dimensions: Is technical trust established? Is psychological trust supported (HT9)?

Additional Predictive Questions

Where will humans interface? Apply HH1 and HH2: What is the lowest self-sufficient level within user complexity tolerance?
What should be visible vs. hidden? Apply HH3: Expose what is actionable, hide what is not, ensure physical constraints that require human response remain visible.
Is this human interface point stable? Apply HH4: Does it satisfy task loop closure, mental model coherence, ownership clarity, trust alignment, and physical boundary alignment?
How should machine and human interfaces differ? Apply HH5: Optimize lower layers for machine consumers, upper layers for human consumers, with clear transition between regimes.

13. Known Limitations and Future Work

This framework has known limitations that future work should address:

Quantification

The framework speaks of complexity, cost, and benefit without providing metrics. A more mature framework would define measurable quantities and thresholds.

Dynamics

The framework is primarily static. While H4, H5, and H6 address evolution, the framework lacks vocabulary for trajectories, rates of change, or dynamic stability.

Multi-Agent Considerations

The explicit exclusion of economic forces and incentives limits the framework's applicability to systems where multiple independent actors make architectural decisions based on local interests.

Human-facing systems exist within social contexts that influence their design and use. The framework addresses individual cognitive constraints but not social dynamics, organizational structures, or cultural factors.

Empirical Validation

The hypotheses are plausible but not yet validated against a systematic survey of real systems. Such validation should test whether platform boundaries empirically correspond to complexity peaks and self-sufficiency boundaries as the framework claims.

Cross-Cutting Concerns

The framework does not adequately address concerns that span multiple platform layers (security, power management, observability, error handling). These cross-cutting concerns require coordination between layers that the current layered model does not fully capture.

Appendix A: Glossary of Terms

Term	Definition Reference
Abstraction	Def 3.14
Abstraction Layer	Def 3.15
Actionability	Def 8.3
Complexity	Def 3.21
Composition	Def 3.13
Computation	Def 3.4
Data	Def 3.1
Human Interface	Def 8.1
Human Task Loop	Def 8.5
Human-Facing Platform	Def 8.6
Interface	Def 3.9
Locus	Def 3.5
Mental Model	Def 8.2
Performance	Def 3.22
Persistence	Def 3.7
Platform	Def 3.16
Platform Completeness	Def 3.19
Self-Sufficiency	Def 3.18
Self-Sufficiency Boundary	Def 3.20
State	Def 3.2
Subsystem	Def 3.12
System	Def 3.10
System Boundary	Def 3.11
Task Loop	Def 3.17
Topology	Def 3.6
Transformation	Def 3.3
Transport	Def 3.8
Visibility	Def 8.4

Appendix B: Dependency Map

The following shows which theorems depend on which axioms and definitions:

Core Framework Dependencies

T1  (Specialization Emergence)      ← A2, A8
T2  (Specialization Tradeoff)       ← A7, T1
T3  (Composition Enables)           ← Def 3.13, Def 3.14
T4  (Composition Cost)              ← T3
T5  (Recursive Composition)         ← T3
T6  (Coordination Necessity)        ← A9, A10
T7  (Coordination Cost)             ← T6
T8  (Concurrency-Consistency)       ← T6, T7
T9  (Communication Requirements)    ← A11, A12
T10 (Communication Overhead)        ← T9
T11 (Reliability Requires)          ← A14
T12 (Reliability Cost)              ← T11
T13 (Error Handling Burden)         ← A16
T14 (Coordination Explosion)        ← T10
T15 (Heterogeneity Burden)          ← A2, A3, A4, T9
T16 (Standard Emergence)            ← T14, T15
T17 (Abstraction Tradeoff)          ← Def 3.14
T18 (Abstraction Layer Value)       ← T14, T15, T17
T19 (Leaky Abstraction)             ← A1, Def 3.14
T20 (Self-Sufficiency Boundary)     ← H1, A17
T21 (Self-Sufficiency Integration)  ← Def 3.17, A17
T22 (Self-Sufficiency Trust)        ← A12, Def 3.20
T23 (Self-Sufficiency Tradeoff)     ← A8, Def 3.19

Human-Facing Extension Dependencies

HT1 (Visibility-Actionability)      ← HA1
HT2 (Physical Leakage)              ← HA4, A1
HT3 (Mental Model Support)          ← HA2, Def 8.2
HT4 (Mental Model Limits)           ← HA1, HA3
HT5 (Human Self-Sufficiency)        ← Def 8.5, T21
HT6 (Self-Sufficiency Mental)       ← HT3, Def 3.20
HT7 (Error Communication)           ← T13, HA1
HT8 (Human Time Scale)              ← HA1, Def 8.5
HT9 (Differentiated Trust)          ← A12, HA2

Hypothesis Dependencies

H1  (Platform Formation)            ← T14, T15, T16, T18
H2  (Multiple Platform Layers)      ← T5, H1
H3  (Platform Services)             ← T9, T14, T15, T16
H4  (Platform Evolution)            ← A15, T19
H5  (Specialization Migration)      ← T1, T2
H6  (Self-Sufficiency Stability)    ← T20, T22

HH1 (Human Interaction Point)       ← H1, T20, HA1
HH2 (Interface Point Determination) ← HH1
HH3 (Visibility Gradient)           ← HT1, HT2
HH4 (Stable Interaction Points)     ← H6, HT6
HH5 (Platform Differentiation)      ← Part I, Part II requirements