Capablio

Handbook

Prompt 12 — Question library, packs, bundles, and adaptive program builder

Implement the core product differentiation: governed question content and an adaptive program builder that can explain and validate every selection rule.

Updated

Required context

  • Adaptive framework wiki pages and domain model
  • Construct → family → variant decisions
  • Cadence/cooldown/coverage/PDP rules
  • Tenant overlay and global catalog governance
  • Entitlements

Prompt

Implement the core product differentiation: governed question content and an adaptive program builder that can explain and validate every selection rule.

1. Question library

Provide list, filters, detail, version history, and authoring for:

  • Constructs
  • Question families
  • Variants
  • Answer scales
  • Observation windows
  • Relationship applicability
  • Cadence applicability
  • Languages
  • Source: global, tenant overlay, tenant owned, imported mapping
  • Status: draft, review, published, retired
  • Usage impact

A family is the stable identity. Editing published wording creates a new version/variant; historical survey content remains immutable.

2. Question quality form

Require or validate:

  • One primary construct
  • Observable behavior/state
  • One primary behavior per item
  • Defined respondent lenses
  • Observation period
  • Scale and anchors
  • Not Observed/NA behavior
  • Default cadence and cooldown
  • Sensitivity/data class
  • Evidence/source and validation status
  • Translation state

Warn on double-barreled wording, unsupported claims, and mismatched horizon. AI authoring may suggest but may not publish automatically.

3. Packs and bundles

Support:

  • Versioned packs with intended audience, cadence, composition defaults, and entitlement
  • Atomic, splittable, ordered, branching, and mutually exclusive bundles
  • Minimum/maximum bundle size
  • Required/optional items
  • Anchor, rotating, PDP, and event item classifications
  • Tenant overlays that enable/disable/weight without mutating source IDs
  • Diff when a global pack updates

4. Program builder wizard

Steps:

  1. Purpose, owner, status
  2. Audience and org scope
  3. Cadence, schedule, timezone, business calendar
  4. Content packs/overlays and relationship routing
  5. Survey size quota and anchor/rotation/PDP allocation
  6. Per-family or policy cooldown
  7. PDP/event override policy
  8. Delivery/reminders
  9. Anonymity, visibility, retention, and consent
  10. Coverage simulation and conflict review
  11. Review, version, publish/effective date

Support save draft, clone, preview as persona, and staged publish.

5. Coverage simulation

Show:

  • Eligible inventory
  • Required/mandatory items
  • Slots per instance and cycle
  • Earliest and expected complete coverage
  • Starving items/bundles
  • Impossible configurations and exact additional quota/time needed
  • Recent exposure/fatigue limits
  • Why a candidate is eligible/ineligible
  • Deterministic preview seed

Do not promise 100% coverage when infeasible.

6. Cooldown semantics

Implement and document:

next eligible period = presented period + skip periods + 1

Support absolute minimum days, rolling ask caps, consecutive-survey caps, configurable exposure scope, and a shared ledger across programs. By default, presented but unanswered counts as exposure; use the approved policy.

7. PDP and mandatory overflow

Reserve capacity for mandatory and force-next-once items. Never silently discard mandatory content. Apply the approved overflow behavior: split, exceed soft quota within hard limit, or block publish and alert.

8. Explainability and audit

For every generated survey, store and expose to authorized admins:

  • Program/version
  • Candidate filters
  • Selected items/bundles
  • Selection reason
  • Exposure and coverage state
  • Deterministic seed/version
  • Overrides

Do not expose respondent-sensitive internals to ordinary participants.

9. Tests

  • Cooldown examples, cadence changes, timezones, DST, business calendars
  • Shared ledger across programs
  • Atomic/splittable/branching bundles
  • Deterministic selection
  • Feasible and infeasible coverage
  • Mandatory/PDP overflow
  • Tenant overlay versioning
  • Plan limits
  • Large inventory performance

Acceptance gates

  • An admin can build and publish a feasible program without editing code.
  • The product explains why questions are selected or blocked.
  • Historical content cannot be silently changed.
  • Coverage forecast and cooldown tests match the approved semantics.