Principle 1
Applications Do Not Own Data — They Access It
The canonical copy of a user’s data is not the application’s to keep.
Applications function as engines of workflow, presentation, and computation —
not as the permanent custodians of records that belong to users or organisations.
User data is exportable, portable, and fully deletable from day one.
Resources are addressable by stable URIs, not coupled to the application’s
internal data model.
Solid-aligned
Architectural effect
Data access is separated from application ownership. Storage and application logic are independent layers with explicit, stable interfaces.
Business consequence
Lower exit cost and preserved data value. The organisation retains its records regardless of which application is in use.
Principle 2
Identity Must Be Portable and Federated
A user’s identity should not be owned by the application. Authentication uses
open standards (OIDC, OAuth 2.0) from the start, even when a local identity
store is the initial implementation. Applications support actors whose
identity may originate outside the application.
Federated
Architectural effect
Authentication is based on portable open standards. Identity can migrate between nodes, providers and partner systems without a structural rewrite.
Business consequence
Lower onboarding friction and less identity duplication. Partners and customers can be integrated without rebuilding authentication from scratch.
Principle 3
Access Control Is a First-Class Domain Concept
Permissions, grants, and consent records are domain objects, not framework
configuration. Access grants are explicit, auditable, and time-bounded.
The system can answer: “Who has access to this resource, why, and since when?”
Solid-aligned
Architectural effect
Permissions become explicit auditable domain records. Every grant has a subject, scope, duration and audit trail — not a boolean flag in configuration.
Business consequence
Clear authority, consent and accountability. The system can produce an evidenced answer to any access-control question.
Principle 4
Data Is Stratified by Ownership and Portability
Not all data is the same. A principled system distinguishes between
application-owned operational data, application-managed user content,
externally stored application-indexed data, and user-controlled interoperable data.
Design decisions identify which level a resource belongs to and handle it accordingly.
Solid-aligned
Architectural effect
Data is classified by ownership and portability at design time. Each category is stored, replicated, exported and deleted according to its class.
Business consequence
Lower duplication, storage cost and regulatory exposure. Sensitive data stays where it belongs and is handled only as needed.
Principle 5
Storage Should Match the Nature of the Data
Different types of data belong in different storage systems. Relational store
for structured records and transactional state. Object store for binary assets.
Cache for transient computed results. External stores for user-controlled resources.
Business logic is expressed in terms of abstractions over storage, not
hard-coded to a specific implementation.
Eco-efficient
Architectural effect
Each data type uses appropriate storage. The application accesses storage through consistent abstractions, making it practical to change or extend underlying systems.
Business consequence
Lower infrastructure cost and better performance. Premium storage is not used for data types that do not require it.
Principle 6
The Request Path Must Be Lean
The synchronous request cycle is not the place for expensive computation.
Authentication checks, cache reads, queue submission, and serialisation of
small result sets: in-request. Image conversion, report generation, external
API fan-out, heavy analytics: deferred to an async task queue.
Lean request paths mean lean compute requirements.
Eco-efficient
Architectural effect
Synchronous application work stays compact. Only fast, low-cost operations occur in the request path; everything else is dispatched asynchronously.
Business consequence
Faster user experience with smaller compute requirements. The system remains responsive under load without requiring larger infrastructure.
Principle 7
Heavy Work Is Inherently Asynchronous
Work that is slow, resource-intensive, unreliable, or long-running belongs
in a task queue, not in the request path. Email dispatch, file processing,
report generation, external API sync, data import/export, cache rebuilding,
webhook delivery, cleanup and archival — all async. Tasks are idempotent,
carry minimum payload, and have explicit retry logic with backoff.
Eco-efficient
Architectural effect
Expensive and unreliable work moves to task queues. The application can handle partial failures, retries and backlog without blocking user sessions.
Business consequence
Better reliability and uninterrupted staff and customer workflows. Long-running jobs complete independently of the browser session.
Principle 8
Systems Should Be Eco-Efficient by Design
The environmental cost of a web system is real. Eco-efficiency is not a
performance optimisation — it is a design value. Systems are sized to their
actual load. Small-server deployment is a viable and well-supported topology.
Caching is used aggressively. Pre-generated artefacts are preferred over
repeated compute.
Eco-efficient
Architectural effect
Compute, storage and network use are deliberately minimised. Caching is aggressive. Pre-generated artefacts are preferred. Infrastructure is sized for actual load.
Business consequence
Lower operating cost and unnecessary capacity removed. Efficient systems cost less to run, upgrade and maintain.
Principle 9
Security and Privacy Are Structural, Not Layered On
Security cannot be retrofitted. TLS on all external and inter-service
communications. CSRF, XSS, and injection protections from day one.
Secrets managed outside the codebase and rotated. Signed URLs for all access
to object storage. Audit trails for any change to access grants or permissions.
Data backups with verified restoration.
Solid-aligned
Architectural effect
Security controls are built into system boundaries from the first line of code. Authentication, authorisation, transport security and secret management are structural, not configuration.
Business consequence
Lower remediation risk and retrofitting cost. Security incidents and compliance gaps are harder to introduce when controls are structural.
Principle 10
Systems Should Be Designed for Federation from the Start
Even if the first deployment is a single-node application, the design does not
assume centralisation is permanent. Resources are addressable by URI, not by
internal database ID alone. Data contracts between components are versioned
and stable. A clean service boundary between application logic and data storage
is the minimum requirement for future federation.
Federated
Architectural effect
Resource and service contracts support future federation. Components are decoupled through stable, versioned interfaces rather than internal coupling.
Business consequence
Preserved options for partnerships, mergers and migration. The application can be federated, split or merged without a structural rewrite.