N. Gallo Nitro Agility S.r.l. 12 August 2026 PIC Architecture and Deployment pic-architecture-deployment-02 Abstract This document is the *PIC Architecture and Deployment Specification*, a subordinate specification of the PIC Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- spec.md). It describes how the components defined by the PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md) and the PIC Sandboxed Execution Specification (https://github.com/pic-protocol/ pic-spec/blob/main/draft/0.2/pic-lineage-guardrail-spec.md) are arranged and operated in concrete systems: the two deployment architectures - *centralized*, where a trusted central continuity service validates continuation requests and issues or authenticates the resulting continuity state, and *decentralized*, where permitted nodes advance continuity locally according to profile rules - their fit to trusted and untrusted environments, hybrid enterprise compositions of the two, and interoperability with existing token infrastructures through a profile-defined OAuth token-exchange binding. This revision describes the architectures; the normative deployment requirements will be developed in forthcoming revisions. This document does not redefine, extend, or alter the PIC Model or the normative semantics defined by the PIC Specification. In case of conflict, the *PIC Specification* is authoritative. Document Status *Project:* PIC Protocol *Project Website:* www.pic-protocol.org (https://www.pic-protocol.org/) *Document:* pic-architecture- deployment-02 *Version:* 0.2 (Draft) *Document Status:* Public Draft *Intended Use:* Informational and Experimental *Published:* 2026-08-12 *Editor(s):* Nicola Gallo (Nitro Agility S.r.l.) *Steward:* Nitro Agility S.r.l. *Source:* github.com/pic-protocol/ pic-spec/draft/0.2/pic-architecture-deployment-spec.md (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- architecture-deployment-spec.md) About This Document Gallo Informational [Page 1] PIC Architecture and Deployment August 2026 *Public Draft — Not a Standard* This document is an independently developed specification published as part of the PIC Protocol and maintained by Nitro Agility S.r.l. in its role as Specification Steward. It has not been adopted, endorsed, approved, or published by the IETF, IRTF, IAB, RFC Editor, ISO, IEC, W3C, CNCF, OpenID Foundation, or any other standards-development organization, unless a later version explicitly states otherwise. It is not an RFC, an Internet Standard, or an official work item of any working group or standards body. This document is published for public review, research, experimentation, implementation feedback, and possible future standardization work. It may be revised, replaced, or withdrawn at any time. Implementers use this draft at their own risk. Any implementation, interoperability statement, or conformance claim applies only to the exact document version identified above. Publication of this draft does not constitute certification, endorsement, security approval, interoperability assurance, regulatory approval, or standards-body recognition. Current project information and published specifications are available at https://www.pic-protocol.org/. Work In Progress This note is to be removed before publishing as an RFC. *Work in Progress — Experimental Design* The deployment and architecture model described in this document is under active development. This model may change substantially before a later stable revision. Implementers MUST NOT assume wire compatibility, semantic compatibility, or backward compatibility with future revisions. Future drafts may introduce breaking changes to terminology, data structures, processing rules, profile bindings, and interoperability requirements. Gallo Informational [Page 2] PIC Architecture and Deployment August 2026 The current text is published for design review, experimentation, and implementation feedback. Editors * *Nicola Gallo* (Nitro Agility S.r.l.) Lead Editor * _Add your name via pull request (individual or organization) — listing is subject to editor approval (see Section 7)._ Contributors * _Add your name via pull request (individual or organization) — listing is subject to editor approval (see Section 7)._ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. Architectures . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Centralized . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Decentralized . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Consecutive Collusion and History . . . . . . . . . . . . 6 3. Trusted and Untrusted Environments . . . . . . . . . . . . . 7 4. Hybrid Enterprise Architectures . . . . . . . . . . . . . . . 8 4.1. Service Meshes . . . . . . . . . . . . . . . . . . . . . 9 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 9. Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This section is non-normative. This specification describes the architectures of PIC systems and their deployment types: centralized and decentralized (Section 2), their fit to trusted and untrusted environments (Section 3), hybrid enterprise compositions (Section 4), and interoperability with existing token infrastructures (Section 5). The components deployed are those of the PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- prover-verifier-spec.md) and the PIC Sandboxed Execution Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-lineage-guardrail-spec.md). Gallo Informational [Page 3] PIC Architecture and Deployment August 2026 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [2] (Section 10) [3] (Section 10) when, and only when, they appear in all capitals, and only within the normative sections of this document. Examples are illustrative and non-normative. 2. Architectures This section is non-normative. This specification defines two deployment topologies, centralized and decentralized; within each, different chain-validation profiles (PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md), Sections 5 and 7) provide different cost and assurance properties. 2.1. Centralized In the centralized architecture, a current continuity state and continuation input are submitted to a trusted central continuity service. The service validates the predecessor state, the proposed advancement, revocation state, non-expansion, request/execution binding when required, and any profile-required evidence. If validation succeeds, it issues or authenticates the next continuity state according to the selected profile. The rest of this document uses *Trust Plane* for such a centralized trusted service. In PIC Profile 0.2, centralized continuity is: trusted settled PIC Token JWT N `-- pic.root = settled PIC Continuity COSE N +-- root.pca = exact signed PIC PCA COSE N bytes `-- transitions = null workload-signed candidate PIC Token JWT `-- pic.root = workload-signed candidate PIC Continuity COSE +-- root.pca = exact signed PIC PCA COSE N bytes `-- transitions = [ exactly one PIC Continuity Transition COSE N+1 ] trusted central validation / settlement trusted settled PIC Token JWT N+1 `-- pic.root = settled PIC Continuity COSE N+1 +-- root.pca = exact signed PIC PCA COSE N+1 bytes `-- transitions = null Gallo Informational [Page 4] PIC Architecture and Deployment August 2026 The trusted settlement service validates the workload-signed candidate and PIC Continuity Transition COSE. It does not centrally sign the workload's Transition COSE; after successful validation it signs the new PIC PCA COSE checkpoint, settled PIC Continuity COSE, and settled PIC Token JWT. PIC-X is a concrete implementation and profile realization of this role, not a required component of the abstract PIC model. +--------+ +--------+ +--------+ | HOP 1 | | HOP 2 | | HOP 3 | +--------+ +--------+ +--------+ \ | / \ | / v v v +---------------------------------+ | TRUST PLANE | | validates continuation state | | issues/authenticates continuity | | uses profile-defined state | +---------------------------------+ centralized advancement produces the next profile-defined continuity state 2.2. Decentralized In the decentralized architecture, a local prover, runtime, or workload advances continuity according to the selected profile without contacting a central service for every hop. The resulting continuity state remains subject to ordinary verification by the receiver and by any later central validation or re-issuance step defined by the profile. This topology is not part of the current PIC Profile 0.2 centralized realization. Profile 0.2 currently defines settlement-authority- mediated advancement only. A future or separate profile may define local advancement, holder-signed settled artifacts, transition- history transport, or other decentralized mechanisms, but those mechanisms are not advertised as Profile 0.2 behavior by this document. +-------------+ +-------------+ +-------------+ | HOP 1 |------>| HOP 2 |------>| HOP 3 | | local P + V | PoR | local P + V | PoR | local P + V | +-------------+ +-------------+ +-------------+ no central component on every hop; advancement and verification follow the selected profile Gallo Informational [Page 5] PIC Architecture and Deployment August 2026 Central validation or re-issuance of locally advanced state is a possible future or separate-profile mechanism, distinct from advancement. It is not part of current Profile 0.2. Such a profile could validate and re-issue the same continuity state: locally issued profile-defined continuity state M | v central validation | v centrally re-issued profile-defined continuity state M Such same-position re-issuance would create no new transition and would not increment position. Current Profile 0.2 does not define this decentralized subchain re-issuance behavior. 2.3. Consecutive Collusion and History An incremental or history-limited profile is secure hop by hop under its selected trust assumptions, with one documented limit (PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md), Section 6.8): two or more consecutive colluding hops cannot be detected when the receiving Verifier lacks authenticated evidence of the earlier lineage prefix. +-------+ +---------+ +---------+ +-------+ | HOP 1 |----->| HOP 2 X |----->| HOP 3 X |----->| HOP 4 | +-------+ +---------+ +---------+ +-------+ colluding hops: without the history, HOP 4 cannot re-check the step from HOP 1 to HOP 2 Continuity history or validation state can be held by the Trust Plane, carried in the continuity artifact, authenticated by external state, checkpointed, compacted, referenced, or committed to by a succinct proof (PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- prover-verifier-spec.md), Sections 5.1–5.3). Carrying the complete prefix makes size and validation cost grow linearly with lineage length, so it is unsuitable as the default lightweight profile; a deployment may nevertheless select full-chain validation when its stronger independent-verification property justifies the O(n) cost. A succinct proof keeps verification cheap but moves the cost to proof generation and adds the proof-system, setup, and availability assumptions. Gallo Informational [Page 6] PIC Architecture and Deployment August 2026 +==============+=========+=============+=============+=============+ |Topology and |Central |History |Cost |Consecutive | |profile |component| | |collusion | +==============+=========+=============+=============+=============+ |Centralized: |yes |profile- |profile- |resisted | |Trust Plane | |defined |defined |under the | | | |history or | |Trust Plane | | | |authenticated| |assumptions | | | |validation | | | | | |state | | | +--------------+---------+-------------+-------------+-------------+ |Other-profile |none |profile- |profile- |not resisted | |decentralized,| |defined local|defined |without | |history- | |state or | |authenticated| |limited | |artifact | |prefix | | | |state | |evidence | +--------------+---------+-------------+-------------+-------------+ |Other-profile |none |complete |O(n) size and|resisted | |decentralized,| |prefix |verification | | |full-history | |carried or |unless | | | | |otherwise |compacted | | | | |available | | | +--------------+---------+-------------+-------------+-------------+ |Other-profile |none |proof commits|succinct |resisted | |decentralized,| |to the |verification;|under the | |succinct proof| |validated |generation |proof-system | | | |prefix |cost per |assumptions | | | | |proof system | | +--------------+---------+-------------+-------------+-------------+ Table 1 The profile trade-offs are analyzed in the PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md), Sections 6.8 and 7. 3. Trusted and Untrusted Environments This section is non-normative. The choice between the two architectures follows the environment. In a *trusted environment* — one whose hops the deployment threat model accepts as trustworthy — consecutive collusion is out of scope: decentralized incremental validation may be sufficient, with no central dependency. In an *untrusted environment* where consecutive collusion is in scope, the deployment must select a profile that independently authenticates the relevant lineage prefix: a Trust Gallo Informational [Page 7] PIC Architecture and Deployment August 2026 Plane, full-history validation, authenticated checkpoints, or an approved succinct-proof profile (Section 2.3). The Trust Plane is one operational choice for bounded validation without advanced cryptography, but not the only profile the model permits. Trust is a property of the deployment threat model, its trust anchors, and the adopted profile — a single administrative domain is not trusted by itself. +=============+==============+====================================+ | Environment | Threat | Suitable topology and profile | | | assumption | | +=============+==============+====================================+ | Trusted | consecutive | decentralized incremental may be | | | collusion | sufficient | | | out of scope | | +-------------+--------------+------------------------------------+ | Untrusted | consecutive | Trust Plane with authenticated | | or high- | collusion in | history, full-chain validation, or | | risk | scope | an approved succinct-proof profile | +-------------+--------------+------------------------------------+ Table 2 The same segmentation drives the guardrail deployment modes of the PIC Sandboxed Execution Specification (https://github.com/pic- protocol/pic-spec/blob/main/draft/0.2/pic-lineage-guardrail-spec.md) (Section 3.4): trusted segments may operate hops in non-sandbox mode; untrusted or high-risk segments use sandbox mode. 4. Hybrid Enterprise Architectures This section is non-normative. Enterprise deployments are rarely uniform: one execution may cross segments with different threat assumptions in the same chain. While execution crosses a segment in which consecutive collusion is out of scope, decentralized incremental verification may be used; when it enters a segment in which consecutive collusion is in scope, the deployment uses the selected collusion-resistant profile - Trust Plane validation, full- history validation, authenticated checkpoints, or an approved succinct-proof profile (Section 3). The PIC invariants are the same everywhere (PIC Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-spec.md); PIC Prover and Verifier Specification (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md), Sections 2.4 and 3.3); only the validation topology, the chain-validation profile, and the resulting assurance assumptions change. Gallo Informational [Page 8] PIC Architecture and Deployment August 2026 The following diagram illustrates the Trust Plane variant of a hybrid deployment. TRUSTED SEGMENT | UNTRUSTED SEGMENT | +-----------+ +-----------+ | +-----------+ +-----------+ | HOP 1 |--->| HOP 2 |-------->| HOP 3 |--->| HOP 4 | | local P+V | | local P+V | | | | | | +-----------+ +-----------+ | +-----+-----+ +-----+-----+ | | | | v v | +-------------------------+ | | TRUST PLANE | | | validates transitions | | +-------------------------+ The segment boundary is an assurance boundary. The receiving Trust Plane is not required to retroactively validate the entire preceding trusted segment unless the selected profile requires full-history validation: assurance for the preceding prefix derives from the trust domain that produced it — presented at the boundary as a checkpoint, snapshot, authenticated state commitment, or full history — and accepted under the receiving side's trust policy. Trust Plane guarantees begin at the accepted boundary. How validation state transfers across Trust Plane boundaries — trust anchors, checkpoint signatures, prefix coverage, key rotation, revocation, trust-domain recognition, optional full-history verification or succinct proofs, and coordinated single-use across domains — will be defined by a future Trust Plane federation profile. 4.1. Service Meshes A service mesh — one administrative domain operating workload identity, mutual authentication, and traffic policy — may be classified as a trusted environment when the deployment threat model accepts it as such: hops inside the mesh then verify locally, as in the trusted segment above. 5. Interoperability This section is non-normative. OAuth is one possible entry mechanism for PIC, not a dependency of the PIC model. A profile may define an OAuth Token Exchange binding that derives initial PIC authority from a validated OAuth access token under an exchange profile and local policy, with execution constraints supplied by the initial continuity proposal when defined by that binding. Gallo Informational [Page 9] PIC Architecture and Deployment August 2026 OAUTH INFRASTRUCTURE PIC +--------------+ token exchange +----------------------+ | ACCESS TOKEN |------------------------>| PIC Token JWT | enter PIC +--------------+ +----------------------+ the trusted PIC PCA COSE checkpoint and settled PIC Continuity COSE are created inside the exchange In the Profile 0.2 / PIC-X realization, the exchange returns a settled PIC Token JWT. The initial PIC PCA COSE is created as the trusted checkpoint inside that process, carried as exact signed bytes in root.pca by the settled PIC Continuity COSE, and referenced by root.pca_hash. The PIC Continuity COSE is carried by the returned PIC Token JWT in pic.root. The returned PIC Token JWT is not an OAuth Bearer token merely because OAuth Token Exchange carries it in an access_token response member. Transport of PIC continuity artifacts is a profile-defined binding; for HTTP, a deployment may use a PIC-Token header. The interoperable parameter names, token-type identifiers, request members, and response semantics for a Profile 0.2 OAuth Token Exchange binding are defined by the selected Profile 0.2 exchange binding specification, not by this informational architecture section. 6. Security Considerations This document describes deployment topology and trust placement; it does not replace the security requirements of the PIC Prover and Verifier Specification or the PIC Revocation Specification. Deployments need to evaluate trusted-service compromise, trust- boundary assumptions, history availability, collusion resistance, and revocation-state availability separately from artifact integrity. Centralized profiles rely on the correctness and availability of the trusted settlement or continuity service. Decentralized and hybrid profiles need to define what each Verifier independently validates, what prior validation or checkpoint state it trusts, and how failures are handled. Transport protections such as TLS, mTLS, broker authentication, or service-mesh policy protect channels and operational exposure, but they do not replace PIC continuity validation, non-expansion checks, freshness checks, or authenticated revocation evaluation. Gallo Informational [Page 10] PIC Architecture and Deployment August 2026 7. Contributors The editors and contributors of this document are listed in the *document header* above. Listing is governed by Appendix B.7 of the PIC Legal Appendices (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md). 8. Acknowledgement The *Provenance Identity Continuity (PIC) Model* — the theoretical framework this specification expresses in normative form — was created by *Nicola Gallo*. It first appeared on Zenodo on 1 December 2025 and is developed in full in the Proof-of-Continuity paper: * Gallo, N. (2025). _PIC Model — Provenance Identity Continuity for Distributed Execution Systems_. Zenodo. zenodo.org/ records/17777421 (https://zenodo.org/records/17777421) (DOI: 10.5281/zenodo.17777421). * Gallo, N. (2026). _Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents_. Zenodo. zenodo.org/records/21285112 (https://zenodo.org/ records/21285112) (DOI: 10.5281/zenodo.21285112). Authorship of the PIC Model remains with Nicola Gallo; the PIC specifications are published and maintained by *Nitro Agility S.r.l.* as Specification Steward. Any work that references, implements, or claims conformance with PIC must preserve this attribution, distinguishing the *PIC Model* (author: Nicola Gallo) from the *PIC Specifications* (steward: Nitro Agility S.r.l.), as required by the *PIC Legal Appendices (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md)* (Appendix B, Attribution; Appendix D, Acknowledgements), which are incorporated into this specification by reference. 9. Legal Notices The appendices governing: * *A.* Use of Automated Language Assistance, * *B.* Authorship, Stewardship, Attribution, and Derivative Works, * *C.* Disclaimer and Limitation of Liability, * *D.* Acknowledgements, Gallo Informational [Page 11] PIC Architecture and Deployment August 2026 are maintained in a single canonical document, the *PIC Legal Appendices (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md)* (draft/0.2/pic-legal.md), and are *incorporated into this specification by reference* as if fully set forth herein. In case of conflict between this document and the PIC Legal Appendices, the PIC Legal Appendices prevail for legal, governance, licensing, and attribution matters. This specification is subordinate to the PIC Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- spec.md), which defines the normative semantics of the PIC Model and is the entry point of the specification set. This document does not introduce new conceptual authority, invariants, or authorship claims beyond those defined in the PIC Legal Appendices. 10. References * [1] Gallo, N. (2026). _Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents_. arXiv:2607.08906 [cs.CR]. arxiv.org/abs/2607.08906 (https://arxiv.org/abs/2607.08906) * [2] Bradner, S. (1997). _Key words for use in RFCs to Indicate Requirement Levels_. BCP 14, RFC 2119. rfc-editor.org/rfc/rfc2119 (https://www.rfc-editor.org/rfc/rfc2119) * [3] Leiba, B. (2017). _Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words_. BCP 14, RFC 8174. rfc-editor.org/rfc/rfc8174 (https://www.rfc-editor.org/rfc/rfc8174) * [4] Jones, M., Nadalin, A., Campbell, B., Bradley, J., & Mortimore, C. (2020). _OAuth 2.0 Token Exchange_. RFC 8693. rfc- editor.org/rfc/rfc8693 (https://www.rfc-editor.org/rfc/rfc8693) Author's Address Nicola Gallo Nitro Agility S.r.l. Email: nicola.gallo@nitroagility.com Gallo Informational [Page 12]