# Input Precedence and Source Truth

Hermes must keep the following roles separate:

1. **Functional-build contract:** `implementation/STEWARD-Functional-Build-Master-Prompt.md` controls implementation completeness, offline truthfulness, AI connectivity, security, testing and readiness language.
2. **STEWARD domain corpus:** `source/steward-domain-pack/` controls administrator terminology, powers, workflows, templates, schemas, agents, CHART–ALIGN–ORBIT, permission concepts and domain guardrails.
3. **Reference architecture and product contract:** `implementation/` resolves how the target product should implement those requirements. A justified deviation requires an approved Activation Card.
4. **Generic Mission Control baseline:** `source/baseline-application/` is working source and a UI/state-machine reference. Its static-only architecture, manual Hermes handoff and localStorage are not the final full-stack acceptance target.
5. **Examples and fixtures:** synthetic examples demonstrate shape and test behavior. They are never evidence about the user, organization, authority, outcomes or backend availability.

Older one-file STEWARD installer language describes a Hermes-native configuration concept. It remains valuable domain source, but it is not proof that a standalone downloadable application, database, authenticated backend, streaming path or runtime control has been implemented. The new functional-build contract takes precedence for target application readiness.

Dated Source Watch entries are seed references. Hermes must verify current versions, status, applicability, conflicts and local overrides before presenting them as evidence. Static links do not equal current legal, regulatory, accreditation or policy advice.

If two sources conflict, preserve the more restrictive safety/data/authority boundary and report the conflict. Never resolve ambiguity by inventing permission, identity, data approval or successful tests.

