Success Scorecard
What it is
A Success Scorecard (Inspark's Performance Brief / PB) is the standing, compact, machine-readable contract for HOW success is measured: where we - and, where relevant, the beneficiary - look to know we are winning. Introduced in In++ v2.3, it is the third named stage of the Intent -> Realization chain, after Realization Strategy, and a core peer-class (Core Entities 24 -> 25).
> Why it exists: every domain that adopts In++ needs a "contract for measuring success". Without a core class each domain reinvents it (artifact debt). v2.3 lifts the universal skeleton into the language and closes the loop Value -> Measure.
Dual form (the §7.10 principle, not a new concept)
The Scorecard is a typical dual-form In++ artifact. The AI-facing form (canonical JSON) is the source of truth a tracking agent reads to compute metrics, build reporting and update the platform unambiguously. The human-facing rendering is the mutually-agreed measurement contract people review and sign off (what we measure, the targets, and the access the Client must provide). The 'audience' field ('beneficiary' / 'internal' / 'both') makes that projection deterministic.
Abstract base (what the core defines)
| Part | Purpose |
|---|---|
| 'derived_from' | Version-pinned link to the Realization Strategy this scorecard measures (semantic formula 24). |
| 'objective' | One sentence defining winning, in outcome terms - the line the whole team holds daily. |
| 'measures' | The machine-readable heart. Each measure: definition, indicator_kind (leading/lagging), direction, baseline/target, bands + algedonic, cadence, computation (method/formula for unambiguous automated tracking), source_ref, and value_ref (link to the Intenture Value item). |
| 'data_access' | Instrumentation and beneficiary obligations: analytics accounts, databases, ad accounts, APIs - each with provider (beneficiary / provider_org / third_party), access_status, and which measures it feeds. |
| 'reporting' | 'to_beneficiary' (cadence + curation) and 'platform_update' (AI-facing instructions to refresh dashboards). |
| 'coverage' | The value-coverage discipline: every must-have Value item should be tracked by at least one measure. |
Clean separation of layers
The core defines structure and obligations; the domain defines content. A domain specializes via a profile (allOf) declaring a 'scorecard_type' (e.g. 'inspark:PB'), mapping its sections onto the core roles and adding domain vocabulary + its own Quality Gate. Same pattern as Realization Strategy and Service Definition.
Reference implementation
The Inspark CVD PB ('scorecard_type: inspark:PB') is the reference profile - the spec Holmes reads to track KPIs, build reporting and update the platform, and the measurement contract agreed with the Client. Canonical core schema: 'schemas-core/v2.3/success-scorecard.schema.json'.