Lite Constraints

Lite Constraints (synthesis constraints, no Python)

You produce synthesis-constraints.json — the file the synthesis chain reads to force unconventional vector combinations and block conventional ones. In the paid pipeline this is generated by the proprietary Python constraints generator reading the proprietary intelligence layer (curated anchors + internal pair-scoring). Here you reason in-context over the per-run growth-factors.json + founder constraints to emit the same JSON shape. You drop the proprietary intelligence-layer scoring entirely — it was scaffolding for how the script picked pairs, not a field the synthesis prompts consume.

⚠️ Clean-room rule

Build constraints only from this run's growth-factors.json + founder-input.md. Do NOT read anything under tactics_DB/. Every vector ID you reference MUST exist in this run's growth-factors.json — never invent IDs and never use IDs you remember from the proprietary DB. Prohibited-combination rules are expressed at the category / theme level plus generic conventional-outcome patterns (clean-room), not as proprietary specific pairs.

Inputs & Output

• INPUT (required): WS/03-think-tanks/demand-generation/growth-factors.json (the LIGHT DB — read its vectors and metadata.category_counts).
• INPUT (required): WS/01-diagnostics/founder-input.md (budget, team size, hours, unfair advantages, stage — to build the founder-leverage pool and bias selection).
• OUTPUT: write WS/03-think-tanks/demand-generation/synthesis-constraints.json.

What the synthesis chain actually uses (build these fields)

1. diverse_white_space (explore + build read this) — 8-10 cross-category vector PAIRS that are genuinely unconventional and exclude over-represented "content flywheel"-type vectors. Each: { "vectors": [id_a, id_b], "reason": "<the emergent angle in plain English>", "source": "white_space" }. Pick pairs whose mechanisms, when combined, would make a generic marketer say "that's unusual / risky" (not "obviously do that").

2. mandatory_combinations (explore + build read these pools) — a flat array; each item has a pool, vectors, reason, priority:

   • Pool A — A_white_space (5): the strongest 5 from diverse_white_space.
   • Pool B — B_synergy (5): high-synergy CROSS-CATEGORY pairs (e.g. Structural + Resource, Leverage + Positioning, Psychological + Leverage, Structural + Psychological, Resource + Positioning). reason: name the synergy type.
   • Pool C — C_founder_leverage (5): pairs that exploit what THIS founder HAS that's rare — their unfair advantages (technical skill, industry access, network, domain expertise, existing audience) — within their time and budget. Both vectors should be transferability "High"; at least one "Emerging". reason: name the asset it exploits. priority: must_include for A/B, suggested for C.

3. prohibited_combinations (Step 1's conventional-detection) — category/theme-level rules that always yield conventional outcomes, each { "pattern": "<theme A> + <theme B>", "vectors_if_present": [<any matching ids from this run, or []>], "reason": "<the conventional mechanism it produces>", "alternative": "<keep one vector, swap the other for an emerging/contrarian one>" }. Always include these generic conventional patterns (map them onto whatever matching vectors exist this run):

   • "customer-research/personal-need" + "content/SEO flywheel" → "talk to customers and write content" (CONVENTIONAL).
   • "build-interesting/demo" + "platform-timing/share" → "build demos and share them".
   • "behavioral-cohort/analytics" + "content funnel" → "segment users and optimize".
   • "community-join" + "audience-borrowing" → "join communities and participate".
   • "content flywheel" + any SEO/authority/backlink vector → "create content to rank".

4. category_diversity_requirements (build reads this) — compute from growth-factors.json metadata.category_counts: { "total_vectors": N, "category_counts": {…}, "minimum_unique_vectors_in_synthesis": {prefix: min}, "max_single_category_pct": 60, "note": "No single category prefix should exceed 60% of vectors used in synthesis output" }.

   Minimum rule per prefix — must be satisfiable, or it is worse than no rule at all:

   • count == 0 → 0. Never 1. A category with no vectors cannot contribute one.
   • share of total < 10% → min(2, count)
   • share of total ≥ 10% → min(3, count)
   • Then cap the whole set: the sum across prefixes must not exceed 12. If it does, shave from the largest minimums first until it fits.

   The cap is the load-bearing part. Synthesis produces 7-9 tactics carrying 2-3 vectors each, so ~12 distinct vectors is the realistic ceiling and ~18 is the absolute one. A share-of-DB rule (the shape the proprietary script uses against a much larger database) inverts on a 20-40 vector LIGHT DB and demands every vector in it.

   Worked example — a real run. 24 vectors: struct- 5, lever- 6, resource- 6, psych- 5, pos- 2, conv- 0. Shares: 21%, 25%, 25%, 21%, 8%, 0%. Minimums: struct- 3, lever- 3, resource- 3, psych- 3, pos- 2, conv- 0 — sum 14. Over the cap of 12, so shave two from the largest: struct- 3, lever- 3, resource- 2, psych- 2, pos- 2, conv- 0 — sum 12. Satisfiable by an 8-tactic set. (The old share rule produced 5/6/6/5/2/1 — sum 25, i.e. "use every vector plus one that doesn't exist." Build silently violated four of the six and nothing noticed.)

Also emit (lite versions of the script's other fields, used loosely by synthesis explore/build):

5. anti_patterns (synthesis-build reads this INSTEAD of the proprietary anti-vector tracking) — a short generic list of demand-gen anti-patterns to reject, each { "pattern": "...", "severity": "HIGH|MEDIUM", "why": "..." }. Always include: fabricated scarcity/urgency; multi-account astroturfing / fake social proof; fake-door pages for nonexistent features; product-dev-disguised-as-marketing (Day-1 is engineering); targeting existing users for upgrades (retention, not acquisition); teaching customers to DIY the product (cannibalization).

6. unconventional_anchors — 4-6 of the most "Emerging", high-transferability vectors from this run, each { "vector": id, "category": "...", "good_partners": [ids], "avoid_partners": [ids of conventional/over-represented vectors], "reason": "..." }.

7. validation_rules — { "min_white_space": 5, "min_synergy_pairs": 5, "max_from_same_anchor": 2, "unconventional_target_pct": 50 }.