Adopt standard policy guidance and document provenance

docs/policy/architecture.md

@@ -1,14 +1,41 @@
-# Architecture
+# Architecture Policy
 
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.3
 
-**Last Updated**: 2026-09-25
+**Last Updated**: 2026-09-28
 
-This document defines Narratio's intended high-level architecture and the
-invariants that changes must preserve. Implemented component details belong in
-the [Internal Overview](../internal/overview.md) and its linked documents.
-Significant architectural decision history belongs under `docs/adr/` when such
-records exist.
+**Upstream Source**: https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md
+
+## Purpose And Ownership
+
+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.
 
 ## System Shape