Constraints

Dos and Don'ts that guide Agent behavior. Constraints are guardrails that prevent mistakes and ensure responsible analysis.

Why This Matters

Constraints prevent:

• Flawed analysis - Agent avoids common statistical mistakes
• Dangerous recommendations - Agent doesn't suggest unfair or unethical actions
• Data misuse - Agent respects privacy and compliance
• Wasted effort - Agent knows what not to waste time on

Constraints set expectations about:

• What's fair vs. unfair in analysis
• What's statistically valid vs. invalid
• What's compliant vs. violating regulations
• What's appropriate vs. inappropriate

Dos and Don'ts Structure

Every constraints section should have:

• MUST DO - Non-negotiable requirements
• MUST NOT - Non-negotiable prohibitions
• SHOULD DO - Strong recommendations (can be violated with justification)
• SHOULD NOT - Strong cautions (can be violated with justification)

Real Example: Poor vs. Comprehensive Constraints

Poor Constraints

Don't make mistakesBe fairCheck your work

Problems:
* Too vague (what mistakes?)
* Not specific enough to guide behavior
* Agent has no concrete guardrails

Comprehensive Constraints

Example for Customer Churn Analysis:

<CONSTRAINTS>

MUST DO:
    - Show the sample size for any analysis (e.g., "of 1,200 customers")
    - Compare churn to historical baseline and seasonal patterns
    - Segment analysis by meaningful groups (tenure, company size, etc.)
    - Validate findings using two independent calculation methods
    - Flag when a segment is too small for reliable analysis (<30 customers)
    - Explain any assumptions made in the analysis
    
MUST NOT:
    - Present correlation as causation (e.g., "usage decline CAUSES churn")
    - Recommend customer termination based on single metric
    - Ignore seasonal patterns (Jan churn always higher due to budget cycles)
    - Make predictions about specific customer actions (privacy violation)
    - Claim that churn can be eliminated entirely (unrealistic)
    - Analyze cohorts with <30 customers without strong caveats
    
SHOULD DO:
    - Consider what metrics best predict who will churn
    - Identify early warning signals (product usage patterns, support tickets)
    - Suggest retention actions specific to each at-risk segment
    - Quantify the financial impact of proposed retention actions
    - Include time-based analysis (when do customers typically churn?)

SHOULD NOT:
    - Over-focus on price as churn driver without other context
    - Recommend expensive interventions without ROI analysis
    - Assume that money alone will solve churn (product issues matter too)
    - Ignore customer feedback about why they left

</CONSTRAINTS>

Constraints by Domain (Real Examples)

Constraints for Healthcare Quality Analyst:

<CONSTRAINTS>

MUST DO:
    - Risk-adjust all physician and unit comparisons using appropriate methodology
    - De-identify all data (no patient names, MRNs, or dates)
    - Show sample size (number of cases) for all metrics
    - Include confidence intervals for small sample sizes (<30 cases)
    - Verify data completeness before making claims
    - Recommend only evidence-based improvements (cite literature)
    
MUST NOT:
    - Expose any Protected Health Information (PHI)
    - Compare physicians without risk adjustment (unfair and unsafe)
    - Make clinical recommendations (only operational insights)
    - Suggest staffing changes without understanding clinical context
    - Claim a practice is "unsafe" based on small sample size
    - Present observational associations as proven causation
    
SHOULD DO:
    - Consult with clinical leadership before publishing comparisons
    - Validate findings with subject matter experts
    - Account for documentation/coding variations between units
    - Consider workforce experience levels when interpreting results
    - Include patient acuity metrics (case mix index) in comparisons
    
SHOULD NOT:
    - Focus only on efficiency without considering patient outcomes
    - Recommend process changes without change management planning
    - Ignore the time lag in data (outcomes data is historical)

</CONSTRAINTS>

Constraints for SaaS Growth Analyst:

<CONSTRAINTS>

MUST DO:
    - Separate new customer acquisition from expansion revenue
    - Account for data lags (churn data is 30-60 days behind real-time)
    - Calculate Net Revenue Retention (NRR) not just customer count
    - Include time lag between action and metric change (expect 3-6 month lag)
    - Segment churn by reason category (price, product, competitor, bankruptcy)
    - Show confidence intervals on predictions (especially for small cohorts)
    
MUST NOT:
    - Make lifetime value claims on cohorts with <6 months history
    - Treat new and expansion customers the same in retention analysis
    - Ignore seasonal variations (Jan churn always different from Dec)
    - Recommend pricing changes without competitive context
    - Present month-to-month churn trends without smoothing (too much noise)
    
SHOULD DO:
    - Identify early warning signals that predict future churn
    - Analyze why expansion rate declined (feature gaps? Pricing? Satisfaction?)
    - Consider customer size and segment in all analysis
    - Validate churn predictions against actual outcomes
    
SHOULD NOT:
    - Assume churn is purely a pricing problem
    - Ignore that early-stage cohorts have higher churn
    - Make commitments about when churn will improve

</CONSTRAINTS>

Constraints for Manufacturing Quality Analyst:

<CONSTRAINTS>

MUST DO:
    - Use statistical process control (control charts) for trend analysis
    - Distinguish normal variation from special cause variation (p<0.05 threshold)
    - Include sample size and inspection method for all metrics
    - Report process capability (Cpk) with confidence intervals
    - Account for rational subgrouping in control limits
    - Verify root causes before recommending process changes
    
MUST NOT:
    - Report defect rates without context of sample size
    - Claim special cause variation without statistical evidence
    - Use control limits from subgroups of different sizes (violates SPC)
    - Assume correlation implies causation in quality defects
    - Make process changes without baseline measurement
    - Report percentages only (use both count and percentage)
    
SHOULD DO:
    - Root cause analysis should consider: materials, equipment, operators, methods
    - Validate control chart signals with process operators
    - Compare current capability to process targets
    - Account for startup periods or known disruptions
    - Include process parameter trends (temperature, pressure, etc.)
    
SHOULD NOT:
    - Tighten specifications without improving process capability
    - Blame operators without understanding process capability
    - Ignore that measurement system variation affects apparent defect rate

</CONSTRAINTS>

Constraint Design Principles

1. Be Specific, Not General Bad: "Be careful with small samples" Good: "Flag when a segment is <30 customers; provide confidence intervals; note unreliability"

2. Anticipate Mistakes For each common mistake, create a constraint:

   • Common mistake: "Comparing customer groups without controlling for differences"
   • Constraint: "Always segment by relevant factors (company size, industry, acquisition source)"

3. Separate Musts from Shoulds

   • MUST = Non-negotiable, always apply
   • SHOULD = Best practice, apply unless there's a good reason not to This gives guidance while allowing judgment.

4. Address Domain-Specific Gotchas Each domain has unique pitfalls:

   • Healthcare: Must de-identify data
   • SaaS: Must account for data lags
   • Manufacturing: Must use control charts
   • Finance: Must account for seasonality Include domain-specific constraints.

5. Provide Clear Thresholds Where Possible Instead of: "Only analyze large enough samples" Use: "Flag analyses with <30 samples; provide confidence intervals; note unreliability"

This gives concrete guidance the Agent can follow.

Common Constraint Mistakes

Mistake	Problem	Fix
Too many constraints	Agent paralyzed, can't decide	Limit to 8-10 key constraints
Vague constraints	Agent doesn't know what they mean	"Flag small samples" → "Flag when N < 30"
Conflicting constraints	Agent can't satisfy all of them	Review constraints for conflicts
No distinction between musts/shoulds	Everything is equally important	Clarify which are non-negotiable
Ignoring domain gotchas	Agent makes domain-specific mistakes	Add domain-specific constraints
Constraints about format not substance	Focus on presentation not analysis quality	Include both but emphasize substance