Clarify ConfigKit design goals and priorities

docs/policy/architecture.md

@@ -2,7 +2,7 @@
 
 **Base Policy Version:** 1.3
 
-**Last Updated**: 2026-09-28
+**Last Updated**: 2026-09-29
 
 **Upstream Source:** [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md)
 
@@ -34,6 +34,23 @@ Do not promote incidental implementation choices into architectural invariants.
 
 ## Success Criteria
 
+ConfigKit prioritizes a coherent configuration model: consistency and
+predictability take precedence over flexibility for accommodating individual
+downstream conventions. Consumers should learn one set of rules, not different
+combination or presence semantics depending on the source format or consuming
+application. Distinct operations such as strict composition and intentional
+overlay express distinct purposes within that model.
+
+Consumers should be able to load once and receive a complete, validated
+configuration with inspectable provenance for its final values, including
+defaults and recorded application-derived values. Configuration and metadata
+together must distinguish explicit zero, false, empty, and null input from
+omission; ordinary Go values alone need not encode those distinctions.
+Application-owned resolution belongs within the recorded loading lifecycle, so
+consumers need no subsequent generic merging, defaulting, or provenance
+reconstruction. This does not transfer domain execution or runtime resource
+management into ConfigKit.
+
 1. **Reduce application infrastructure:** Can applications delete substantial
    configuration infrastructure while retaining clear ownership of their domain
    rules?
@@ -41,8 +58,11 @@ Do not promote incidental implementation choices into architectural invariants.
    configuration model, with only the flexibility needed to express genuine
    application requirements?
 
-Both criteria must hold. ConfigKit should not preserve divergent consumer
-conventions merely for compatibility, nor impose restrictions that prevent useful
+Both criteria must hold. Minimize consumer loading and processing code subject
+to the consistency, presence, and provenance principles above, rather than
+trading those principles for consumer-specific shortcuts. ConfigKit should not
+preserve divergent consumer conventions merely for compatibility, nor impose
+restrictions that prevent useful
 domain information from being expressed. Prefer a canonical representation using
 existing primitives before adding another mechanism. Extend the model when a
 concrete requirement cannot be accommodated cleanly, not simply because a