Assumptions and Architectural Decisions

Product scope

Capablio is treated here as an adaptive feedback and development system rather than a full HRIS, payroll system, learning-management system, or compensation suite.

Its primary jobs are:

• Collect small amounts of useful feedback at the right time.
• Preserve enough stable measurement to show trends.
• Route relevant questions to people who can actually observe the behavior.
• Connect feedback to a personal development plan.
• Prevent survey fatigue through cooldowns, quotas, and coverage-aware rotation.
• Support annual or quarterly 180/360 reviews without making every check-in a formal review.
• Accept external evidence, including Thomas reports, without allowing an imported framework to constrain the internal model.

Product principles

Development before judgment

The default use case is growth and self-awareness, not automated employment decisions. A tenant may export data into a performance process, but the product should clearly separate development feedback from formal evaluation.

Observable behavior before abstract traits

Questions should ask about behavior, conditions, actions, or outcomes that the respondent could reasonably observe during a stated period.

Right respondent, right horizon

A customer should not be asked about internal succession planning. A direct report should not be asked to judge enterprise portfolio economics unless they have the necessary exposure. A daily prompt should not ask whether a leader “consistently develops successors.”

Longitudinal continuity without repetitive wording

Constructs and question families are stable. Exact question variants may change by cadence and respondent lens.

Short surveys, complete programs

Each survey is intentionally incomplete. The program becomes complete over time through anchors, rotation, and coverage accounting.

Explicit uncertainty

Reports must show sample size, Not Observed rates, dispersion, source, and observation horizon. Small decimal differences should not be treated as meaningful by default.

Tenant flexibility with framework integrity

Tenants may add questions and overlay packs, but they should not silently edit a published global item that already has responses. Customization is versioned and auditable.

Key decisions

1. Use Construct -> Question Family -> Question Variant; do not make the exact question text the only identity.
2. Name the re-ask concept exposure_cooldown, not retention_period.
3. Maintain one global exposure ledger per subject–respondent–question-family scope, so the same item is not repeated through two overlapping schedules.
4. Interpret skip_periods = N as: after presentation in period P, skip periods P+1 ... P+N; next eligibility is P+N+1.
5. skip_periods = 0 means eligible in the next survey instance after the current one. It never creates a duplicate inside the same survey.
6. Count a presented but unanswered question as an exposure by default, because fatigue occurs even when the respondent skips it. This is configurable only at policy level.
7. Use deterministic constrained selection, not uncontrolled random choice.
8. Reserve capacity for mandatory and PDP items before selecting rotating items.
9. Never silently discard mandatory questions. Split the survey, exceed the soft quota within a hard limit, or alert the administrator.
10. Treat imported Thomas results as external baseline evidence. Preserve raw values and source context; do not blend them into Capablio trend lines by default.
11. Separate commercial entitlements, tenant policy settings, and engineering feature flags.
12. Charge for managed subjects, not respondents. Invited raters should be free.

Non-goals for the first product version

• Psychometric adaptive testing based on item-response theory.
• Automated diagnosis of personality, mental health, or protected characteristics.
• Automatic creation of a PDP from a single low score without user or manager confirmation.
• Organization-wide normative benchmarks before sufficient, consented, comparable data exists.
• Replacing a formal HR investigation, grievance channel, or whistleblowing system.
• Ranking individual engineers using delivery telemetry.

Minimum quality bar for a question

A published question must have:

• One primary construct.
• One observable behavior or state.
• A defined respondent relationship.
• A defined observation window.
• A compatible answer scale.
• Separate Not Observed and Not Applicable options where appropriate.
• A cooldown and maximum exposure policy.
• A stable family identifier and immutable version.
• An owner, source, status, and review date.
• A clear statement of whether it is suitable for trend analysis.