NeMo documentation places chat templates inside the deployment trust boundary

The problem is an assistant that passes ordinary tests but inherits unreviewed behavior from imported configuration. Engage application owners, developers and security. Ask who may modify prompt construction, how changes reach production and what external actions the assistant can take. A bounded configuration review for one workflow could clarify ownership and identify uncontrolled changes. The value hypothesis is more dependable release governance, subject to testing. Do not characterize every custom template as malicious or promise that a license, sandbox or review eliminates prompt injection.

Capture the effective configuration at deployment rather than reviewing only a repository default. Require approved model artifacts, a test identity and synthetic records. Validate precedence through a harmless controlled change and confirm that unauthorized edits are denied. Compare output behavior with the accepted configuration on benign and adversarial cases. Keep external tool execution behind independent authorization. The proof of value should demonstrate traceability from reviewed artifact to running service and rollback without exporting sensitive traces. It does not certify the model itself.

The application service owner should coordinate developers, security reviewers and platform operations. Establish a change log, approval workflow, regression corpus and rollback procedure. Dependencies include reviewer time and visibility into deployed settings. Train maintainers to inspect effective behavior after updates and users to report unexplained output changes. Review configuration before broader adoption and after supplier changes. Proposed acceptance criteria are complete artifact traceability, blocked unauthorized edits and successful rollback of a staged change. Risks include emergency overrides and behavioral drift outside the test corpus.