Align architecture and source release policies

docs/policy/architecture.md

@@ -1,22 +1,46 @@
-# Architecture
+# Architecture Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated**: 2026-09-26
+**Last Updated**: 2026-09-28
 
-Notarius adapts the base template to its fixed pipeline, artifact families,
-external adapters, state boundaries, and source-only distribution.
+**Upstream Source**: https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md
 
-This document defines the intended high-level architecture of Notarius and the
-invariants that changes must preserve. Implemented component details belong in
-[Internal Overview](../internal/overview.md) and its linked documents. The
-reasoning behind significant architectural choices belongs in
-[ADRs](../adr/).
+## Purpose And Ownership
 
-An adopted constraint can govern future changes without implying that every
-component it could govern exists. Descriptions of implemented structure must
-remain accurate; proposals and transition status belong in roadmaps and ADRs.
-Constraints reflect selected requirements, not incidental implementation choices.
+The adopted policy defines the application's purpose and the architectural
+constraints contributors must follow. It owns system boundaries, responsibility
+and dependency rules, established invariants, and explicit non-goals.
+
+Describe the concrete package inventory and implementation mechanics in internal
+documentation. Link to canonical public contracts for their exact behavior and
+to ADRs for decision rationale.
+
+## Architectural Approach
+
+Hexagonal architecture is strongly recommended, including encapsulating external
+integrations and APIs within internal adapters. Keep domain and application
+logic independent of external integration details, and make dependency direction
+clear in the adopted policy.
+
+Implement that separation with proportionate, idiomatic code. Choose interfaces
+and package layout to serve the application's actual boundaries. Use adapters
+for collaborators with external integration responsibilities.
+
+## Adopted Constraints And Implemented Structure
+
+Architectural constraints govern current and future development. Record
+implemented structure accurately, proposals and implementation status in the
+roadmap, and significant decisions and rationale in ADRs. Describe a target
+structure as implemented when its changes land.
+
+Constraints must reflect deliberately selected requirements and decisions.
+Do not promote incidental implementation choices into architectural invariants.
+
+Notarius's fixed pipeline, artifact-family boundaries, and deployment-owned
+cache permissions are established product decisions. The linked ADRs retain
+their rationale; the [internal overview](../internal/overview.md) inventories
+their implementation.
 
 ## System Shape
 
@@ -291,6 +315,21 @@ LLM provenance to make a run auditable after configuration changes. Manifests
 record identities and bounded validation summaries rather than secret, raw
 model, correction, or large payload content.
 
+## Trust Boundaries And Threat Scope
+
+Where useful, state the trust boundaries and threat scenarios relevant to the
+application's adopted requirements, along with scenarios it explicitly excludes.
+For example, distinguish handling untrusted application input from defending
+against a privileged actor concurrently modifying the host filesystem.
+
+Threat exclusions define the scope of the adopted requirements. Base defenses
+and guarantees on those requirements and raise unsettled scope for a deliberate
+decision under the [agent policy](agents.md).
+
+Keep this discussion proportionate to the application. Configuration,
+operations, and internal documents retain ownership of credential supply,
+runtime handling, and implementation mechanisms under the documentation policy.
+
 ## State, Output, And Safety
 
 Source material and model responses cross application validation boundaries.