Align architecture documentation and testing policies with current standards

docs/policy/architecture.md

@@ -1,11 +1,25 @@
 # Architecture
 
+**Base Policy Version:** 1.1
+
+**Last Updated**: 2026-09-25
+
+**Upstream Source:** `policy` commit `45591a79004c6811950f14dca554f6ff69b7f58e`.
+
+Notarius adapts the base template to its fixed pipeline, artifact families,
+external adapters, state boundaries, and source-only distribution.
+
 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/).
 
+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.
+
 ## System Shape
 
 Notarius is a small, dependency-light Go application for extracting structured
@@ -281,6 +295,13 @@ model, correction, or large payload content.
 
 ## State, Output, And Safety
 
+Source material and model responses cross application validation boundaries.
+Host access policy belongs to the deployment; hypothetical privileged actors
+concurrently changing the filesystem do not justify new application defenses
+without an explicit decision. This scope statement does not remove the adopted
+correctness boundaries below or claim excluded scenarios cannot occur. Follow
+[Agent Policy](agents.md) when a new threat or guarantee needs a decision.
+
 Notarius exposes three filesystem surfaces with independent roots and
 lifecycle: