Add offline proposal assessment observation example

docs/policy/testing.md

@@ -64,13 +64,15 @@ Introducing hosted CI later would supplement, not silently redefine, this
 documented validation model.
 
 Full release-candidate validation includes race-enabled package tests, explicit
-static analysis, and execution with automated semantic checks of both maintained
+static analysis, and execution with automated semantic checks of the three maintained
 offline consumer examples. The test run builds the packages; the examples
 also exercise ordinary compilation. Separate ordinary tests and a standalone
 build are not additional release gates. Ordinary tests remain useful during
 development. The preparation example protects assembled preparation and
 inspection behavior. The execution example separately protects assembled
-`Run`, injected-client, validation, usage, and result behavior.
+`Run`, injected-client, validation, usage, and result behavior. The observation
+example protects assembled built-in retries, structured proposal and assessment
+runs, and application-owned interpretation of metadata.
 
 Tests in the default suite must be deterministic, offline, and independent of
 real credentials. They must not invoke paid APIs, use live network
@@ -96,7 +98,7 @@ Use each test type where it protects a distinct risk:
   interaction, while replacing live or nondeterministic external boundaries.
 - External-package root tests exercise the public facade as a Go consumer,
   while internal package tests own focused implementation behavior.
-- The maintained offline preparation and execution examples protect distinct
+- The maintained offline preparation, execution, and observation examples protect distinct
   representative assembled consumer workflows without contacting a model
   provider.
 - Fixtures should be minimal, synthetic, versioned with the behavior they