CRM AI production-readiness checklist

Deterministic list. Every item is done or not done, and the enforcement block is the one that decides whether a bad day becomes a bad quarter.

If you want the reasoning behind any of these, the main guide develops each one. This page is the block to check against.

Enforcement, in code and not in the prompt

• The CRM connection is read-only, at the integration user's permission set
• The object whitelist is checked server-side and returns an explicit error
• The field allowlist is checked against the finished query plan, after the model has stopped planning
• A non-allowlisted request fails identically every time, so it is testable
• The guidance allowlist and platform CRUD, FLS, and sharing agree with each other
• Someone has confirmed which permission set can read the rules store itself
• Rule write access is narrower than rule read access
• No rule body interpolates user-editable CRM text

Rules

• Every exclusion, anti-pattern, temporal, currency, and security rule is marked always-load
• Every title states a condition, not a category
• Every exclusion is phrased as a pre-flight instruction, not a description
• Rules carrying a predicate ship the predicate, not prose describing it
• Cross-object rules declare dependsOn rather than assuming co-retrieval
• Conflicting active rules are detected in CI, not resolved by retrieval order
• Every AI-generated field has an entry marked non-authoritative
• Rules require approval before reaching status: active

Retrieval

• Phase 1 loads globals and always-load rules on every question
• Phase 2 loads an index of every active rule, not just the starting scope
• Rules are fetched mid-plan before querying any newly introduced object
• Missing required guidance stops the run or routes to review, never proceeds partially
• The guidance text itself tells the agent to cache for the session
• No user-specific or record-specific context sits in a shared cached prefix

Disclosure

• Answers state the rules applied, the exclusions applied, the exact date range, and whose permissions ran
• Empty results on sharing-restricted objects are never reported as "no records exist"
• Permission-suppressed nulls surface as errors rather than as blanks

Testing and observability

• Every rule has at least one golden question that fails without it
• The broad and adversarial tiers both run before release
• Each run logs guidance version, rule ids loaded, planned vs. actual objects and fields, tool calls, answer or refusal, latency, and cache hit or miss
• Rule-text changes and retrieval changes deploy separately
• A one-click rollback to full, unphased guidance exists
• Dynamic retrieval is behind a per-user or per-workflow flag

The three that get skipped

"Checked against the finished query plan." Validating what the model said it wanted is not the same as validating what it's about to run. The check belongs after the reasoning stops, on the actual plan.

"Fails identically every time." A boundary that sometimes refuses and sometimes negotiates can't be tested, which means it isn't a boundary. This is what GQ-01 through GQ-04 verify.

"Rule ids loaded." Without them, a bad answer reported three days later is a story rather than a bug. You cannot write a corrective rule for a failure you can't reconstruct.

If you can't tick the enforcement block, you don't have a context layer yet. You have a well-documented suggestion.

• How to build a CRM AI context layer — the reasoning behind every item
• Permissions and safety — the enforcement block in depth
• Golden-question testing — the testing block in depth
• Operating a context layer — what to watch once it's live