Customer risk implementation checklist

Documentation status: tutorial — see Maturity and evidence.

Use this checklist before considering the worked example reproduced.

[ ] Application configuration activates the risk package.
[ ] Manifest exposes unique stable identifiers for Customer, RiskRequest, RiskIndicator, RiskReviewProcess and RiskDecision.
[ ] Memory configuration loads and resolves every concept before persistence is enabled.
[ ] Request-to-customer and indicator-to-request relationships are conceptual relations with explicit persistence projections where needed.
[ ] Required customer, score-range and finalization constraints are enforced outside the visual layer.
[ ] Published actions have stable business names and typed parameter meanings.
[ ] RiskReviewProcess owns cross-object/asynchronous coordination.
[ ] Significant transitions emit semantic events.
[ ] Review view uses DataSet/DataSource/DataCursor surfaces and keeps local UI events local by default.
[ ] Only stable actions are exposed through services.
[ ] Authentication, authorization, validation and process-state checks remain active at publication boundaries.
[ ] AI context is bounded to authorized conceptual data and actions.
[ ] Human approval is encoded as a process requirement when needed.
[ ] Tests cover loading, model validity, actions, events, process continuation, views, services, .NET local/RPC parity and AI guardrails.
[ ] Evolution tests protect role paths, action signatures and event names.

If all items pass, a developer can reconstruct the same architecture from the site without relying on the declarative book for a missing construction step.