Alternative Recommendation Review

Do not assume every comparison must include ease of integration, security, or operational cost—use them only when they are relevant to the user’s context, criteria, or the nature of the decision.

Workflow

1. Restate both options in one short paragraph each, neutrally.
2. List the criteria you will use (bullet list), and note where each came from (user prompt, prior chat, or inferred—and if inferred, say why briefly).
3. Compare option A vs option B against those criteria only. Skip dimensions that do not apply; do not pad with generic sections.
4. State clearly: agree, disagree, or partially agree with adopting the alternative relative to the baseline.
5. Explain how your stance changes, if at all: adopt, reject, or hybridize—and what evidence would flip you.
6. If the alternative or baseline lacks information needed for a criterion that matters, say what is missing instead of inventing it.

Output format

Use headings and bullets that match the criteria you actually used. The following is only an illustration when integration and security happen to matter:

• Verdict: [agree / disagree / partial] — [one line]
• Criteria used: [bullets]
• Integration analysis: [short] (example dimension—omit if not relevant)
• Security analysis: [short] (example dimension—omit if not relevant)
• Other dimensions: [only as needed, e.g. UX, cost, time-to-ship, team familiarity]
• Updated recommendation: [what you would do now]

Example

Prior: managed Postgres + migrations in-repo. Alternative: SQLite per tenant. User cares about multi-tenant isolation and backup. Verdict: partial — SQLite wins local simplicity but fails the stated isolation/backup bar unless augmented; would not adopt as-is.