Status: public architecture abstract v0 Date: 2026-06-15 Author: Antun Jurkovikj Boundary: Public architecture abstract. This is not legal advice, not a patent filing, not a standards submission, not a production-readiness claim, and not an implementation specification.
Portable Authority Public Projection: Separating Web Publishing Authority From Public Serving
Portable Authority Public Projection (PAPP) is a publishing architecture that separates canonical authority from public serving.
In a typical web publishing system, the public host often stores the live database, exposes the admin surface, runs mutation-capable code, and serves visitors. PAPP separates those roles. The authority remains portable and owner-controlled, while public infrastructure receives an implementation-defined verified projection and serves it without becoming the canonical writer.
Short form:
portable authority decides
public projection serves
"Portable authority" does not require every owner to self-host hardware. The authority can be self-hosted, enterprise-hosted, or managed by an authority-hosting provider. The defining property is that canonical authority remains separable from public projection and portable under the owner's control.
Many publishing systems combine four concerns in one public runtime:
- canonical state;
- admin and write authority;
- plugin or application execution;
- public visitor serving.
That coupling is convenient, but it creates a structural risk: the public-facing host also becomes the source of truth. If that host is compromised, misconfigured, operationally constrained by a provider, or modified by unsafe automation, canonical state is exposed to the same blast radius as public serving.
PAPP addresses this by making public infrastructure replaceable relative to portable authority.
PAPP uses two distinct roles.
Portable authority:
- owns canonical state;
- decides what is eligible for publication;
- retains governance, review, and audit context;
- exports bounded public projection releases;
- remains movable across self-hosted, enterprise-hosted, or managed authority environments.
Public projection:
- receives a bounded projection release;
- verifies the release before serving or materializing it;
- serves public output;
- does not become the canonical writer;
- can be rebuilt or replaced from retained release evidence, depending on implementation policy.
A simple topology is:
Portable Authority A
canonical state and release decision
|
| verified projection release
v
Public Projection C
public serving without canonical write authority
The architecture can include staging or multiple public projections, but the main rule remains the same: public projection nodes do not become canonical authority.
Portable authority can be self-hosted, enterprise-hosted, or managed by an authority hosting provider.
The defining property is not physical location. The defining property is that canonical authority remains separable from public projection and portable under the owner's control.
This creates two logical hosting roles:
- authority hosting: manages canonical state, governance, review, release evidence, and portability;
- projection hosting: serves verified public projections and can be replaced or rebuilt from retained release evidence, depending on implementation policy.
One provider can offer both roles, but PAPP keeps them logically distinct. The public serving target should not become canonical authority merely because it serves public traffic.
A PAPP implementation should preserve these principles:
- public serving and canonical authority are separate roles;
- public projection is explicit and bounded;
- public projection verifies releases before use;
- public projection does not advance canonical authority;
- authority-side review/audit context is not required on the public serving node;
- unsupported or unsafe release shapes fail closed;
- public projection state can be rebuilt from retained release evidence, depending on implementation policy;
- public infrastructure remains replaceable.
PAPP changes the hosting question from:
Which public host owns the live mutable site?
To:
Which portable authority owns the state, and which public targets serve verified projections?
This creates a deployment category between conventional CMS hosting, static publishing, and headless architectures.
Conventional public CMS hosting is mature and simple, but the public host is usually the live authority.
Static publishing makes serving safer and cheaper, but often loses runtime behavior.
Headless architecture separates frontend and backend, but usually requires a new frontend stack and still leaves authority somewhere else.
PAPP focuses on a different boundary: authority versus projection.
As AI agents and automated tools become more common, publishing systems need stronger boundaries around mutation. Tool access alone is not enough. Systems also need review, verification, release boundaries, rollback evidence, and public nodes that do not automatically gain canonical write authority.
PAPP is not an AI protocol. It is an authority and publication boundary that can make agent-assisted publishing safer.
The first implementation direction is WordPress-oriented: keep WordPress authority portable and owner-controlled, then publish a verified read-only projection to a separate public WordPress runtime.
The public runtime should be treated as a projection target, not as the canonical owner. It can serve public traffic, but it should not publish canonical state, merge authority-side changes, or export private governance context.
This is intentionally narrower than full multi-writer synchronization. The first goal is a defensible authority/projection split.
PAPP is not:
- blockchain;
- trustless consensus;
- a claim that hosting is unnecessary;
- a replacement for CDN infrastructure;
- a claim that every plugin or data type is automatically supported;
- a claim that public nodes can safely become canonical writers;
- a production-readiness claim for any specific implementation;
- a disclosure of implementation internals.
PAPP is intended to reduce custody-based hosting lock-in. It does not eliminate operational responsibility.
PAPP is not anti-hosting. It changes the role of hosting from custody of the live public mutable site toward authority services, projection operations, release verification, monitoring, and evidence retention.
Safe public claim:
Portable Authority Public Projection separates canonical publishing authority from public serving. The owner-controlled authority decides what is published; public infrastructure serves verified projections without becoming the source of truth.
Avoid claiming:
- production readiness;
- complete plugin compatibility;
- CDN-scale performance;
- no lock-in ever;
- public multi-writer authority;
- implementation-specific security guarantees;
- standards compliance.
This abstract establishes the high-level architecture and vocabulary without disclosing implementation details.
It intentionally avoids:
- bundle formats;
- verifier internals;
- service-manager details;
- deployment commands;
- exact runtime paths;
- current operational limitations that are not relevant to the architecture abstract;
- unreleased implementation mechanics.
Copyright (c) 2026 Antun Jurkovikj. All rights reserved.
This document describes an architecture direction. It is not a license grant, production promise, or implementation specification. No implementation license, patent license, trademark license, or standards commitment is granted by this abstract.