Referenz — Decision System

architectures.schema.json

architectures file

The architectures (positions) — the spine of distinct structural stances a solution can fill (e.g. Komplettlösung → Eigenbau). The board groups solutions by architecture via solution.architecture → architectures[].key. A bare array of architecture records. Instance extensions narrow via allOf + $ref to this $id with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`key` required	string	Stable selector — the value solutions reference via solution.architecture (a `key`, not an `id`).
`name` required	string	Display name of the position.
`longName`	string	Optional longer/qualified name.
`summary`	string	What this position is — the structural stance in one paragraph.
`optimizes`	string	What the position optimises for — its strength.
`tradeoff`	string	What it gives up — its cost, one line.
`anchor`	boolean	Marks a comparison-anchor position (a ceiling/contrast exhibit, not a serious candidate).
`status`	string	Optional board status for the position.
`clientCopy`	object	Client-facing register (blurb/what/wins/gives-up, …) — permissive; the shell renders it as the public copy.
`verdict`	object	The authored verdict on the position — as-of marker plus the evidence it rests on.
`asOf`	string	Round marker the verdict was last set (e.g. 'R4').
`basis`	array<string>	Finding ids the verdict rests on (resolved against research-index in the semantic tier).

config.schema.json

config file

Cockpit configuration — the weighting model and category spine the kernel scores under. Drift fixed per Plan 15 drift ①: the canonical keys are `weights`/`presets` (every instance ships these; the prose contract's former `weightTriple`/`weightingPresets` are retired). Instance extensions narrow via allOf + $ref to this $id and add their own keys with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`_comment`	string	Free-text authoring note; ignored by the kernel.
`title` required	string	Cockpit title — the engagement/solution name shown in the shell header.
`subtitle`	string	Optional one-line subtitle under the title.
`tierWeights`	object	Default Fit weight per criterion tier — how much a criterion contributes to the Fit sum given its `tier`. Keys are the tier names; values are positive numbers.
`critical`	number	Weight applied to tier:critical fit criteria.
`standard`	number	Weight applied to tier:standard fit criteria.
`nice-to-have`	number	Weight applied to tier:nice-to-have fit criteria.
`weights` required	object	The three-axis blend — how Fit, Cost and Risk combine into the headline comparison. The active blend the cockpit opens with (a preset may override it).
`fit` required	number	Relative weight of the Fit axis.
`cost` required	number	Relative weight of the Cost axis.
`risk` required	number	Relative weight of the Risk axis.
`presets` required	array<object>	Selectable weighting stances (e.g. 'Ausgewogen', 'Günstigster Betrieb') — each a named override of `weights` the user can switch between.
`key` required	string	Stable selector for the preset.
`label`	string	Display name shown in the preset switcher.
`weights` required	→ weightTriple	The fit/cost/risk blend this preset applies when chosen.
`fit` required	number	Relative weight of the Fit axis.
`cost` required	number	Relative weight of the Cost axis.
`risk` required	number	Relative weight of the Risk axis.
`recommended`	boolean	Marks the preset the cockpit opens on / highlights as the default stance.
`reasons`	string	Optional consultant-authored prose rationale for this stance — rendered (escaped) by the shell only when this preset is the active recommended one.
`categories`	array<object>	The solution categories the board groups by. Single-category instances ship one entry; the multi-category explorer (skischule) ships several, each pointing at its own solutions/matrix file.
`key` required	string	Stable category selector.
`label` required	string	Display name for the category tab/section.
`solutionsFile`	string	Optional filename of the solutions file backing this category (when solutions are split per category).
`matrixFile`	string	Optional filename of the per-category tool matrix (instances with a separate tool layer).
`scenario`	object	Shared costing scenario the TCO/Cost axis prices every solution under (e.g. day rate, amortisation years). Shape is instance-specific beyond the common day-rate/amortisation pair; kept permissive here and pinned in an extension if needed.
`dayRate`	number	Person-day rate used to price build/maintenance effort into money.
`amortYears`	number	Years over which one-off costs are amortised for the TCO band.

decisions.schema.json

decisions file

The decisions / values layer — the side-ledger of open forks that accrues across ALL phases (Plan 15 MR-4: decisions are not a phase). A fork narrows the live solution space; its options prune a typed reference set (Plan 15 MR-1: architectures | solutions | fillers, instance-declared). Instance extensions narrow via allOf + $ref to this $id with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`meta`	object	Header context for the decisions layer — what it is, the principle behind it, and the legend that defines each fork's `scope`.
`title`	string	Title of the decisions layer.
`purpose`	string	What the decisions data is and where it sits relative to the ratings layer.
`status`	string	Maturity note (e.g. HYPOTHESE until the review).
`principle`	string	The guiding principle (e.g. 'values above, ratings below').
`scopeLegend`	object	Defines the vocabulary of fork `scope` values — each key is a scope an instance uses, each value explains it. The semantic tier enforces forks[].scope ∈ keys(scopeLegend).
`resolutionModes`	object	The ways a fork gets resolved (e.g. 🎯 value / 📊 rating / 🔍 fact) — keyed by mode name. The semantic tier enforces forks[].modes[] ∈ keys(resolutionModes).
`forks` required	array<object>	The open decisions. Each fork poses a question; choosing an option narrows the live set. Resolution of cross-references (option prune targets, dependsOn.fork, scope, modes) happens in the semantic tier.
`id` required	string	Stable fork id (e.g. F-1).
`title` required	string	Short internal title of the fork.
`question` required	string	The decision question in plain language.
`decides`	string	What resolving this fork actually settles.
`status`	string	Where the fork stands (e.g. 'offen', 'delegiert an Deep-Dive').
`modes`	array<string>	Resolution modes that apply — each ∈ keys(resolutionModes) (checked semantically).
`scope`	string	The fork's scope — a key defined in meta.scopeLegend (checked semantically). Typed as string because scope vocabulary is instance-defined.
`dependsOn`	object	Optional gating — this fork only becomes live once another fork has been resolved a certain way.
`fork`	string	The id of the fork this one depends on.
`option`	string	The option key on that fork that activates this one.
`resolvesWith`	string,null	What input resolves the fork (e.g. a deep-dive, a meeting fact), or null if open with no pinned resolver.
`clientCopy`	object	Client-facing register of the fork (title/question/options) — permissive; the shell renders it as the public copy.
`eliminated`	array<object>	Options already ruled out, with the reason — kept for the audit trail.
`key`	string	The eliminated option's key.
`label`	string	The eliminated option's label.
`why`	string	Why it was eliminated.
`options`	array<object>	The choices on this fork. Choosing one keeps its prune set live and drops the rest.
`key` required	string	Stable option key (selected in the cockpit).
`label`	string	Display label for the option.
`note`	string	Optional rationale/detail shown with the option.
`live`	boolean	Whether the option is currently a real, walkable choice (vs. a contrast exhibit).
`default`	boolean	Marks the option taken when the fork is unresolved.
`prune`	object	MR-1 generalized narrowing: which typed set this option keeps live. The kernel intersects `keep` across chosen options of the same set.
`set` required	enum	Which reference set this option narrows. `architectures` · `solutions` · `fillers`
`keep` required	array<string>	The keys (of that set) this option keeps live; resolved against the target file in the semantic tier.
`reviewAgenda`	object	How the forks are organised for a client review — which the client decides, which we resolve by numbers/facts, plus any gate-hinges and meeting facts. Shape is largely instance-specific (ehimare carries gateHinges/meetingFacts); kept permissive here.
`clientDecides`	object	The forks the client must decide, with an ordering note.
`weDecide`	object	The forks we resolve on the client's behalf by rating/fact.

fillers.schema.json

fillers file

The building blocks (Bausteine) that fill gaps a core solution leaves — the dockable components a solution's coverage references via `part:<id>`/`aug:<id>`. Backs the 'Bausteine nach Aufgabe' view. Instance extensions narrow via allOf + $ref to this $id with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`_comment`	string	Free-text authoring note; ignored by the kernel.
`glueId`	string	The id (a key in `fillers`) of the integration/glue block — rendered last, as the connective layer every composed solution needs.
`order`	array<string>	Display order of the filler cards, by filler id.
`fillers` required	object	The blocks themselves, keyed by filler id. A solution's coverage suffix (part:<id>/aug:<id>) resolves to a key here in the semantic tier.

landscape.schema.json

landscape file

The raw, un-scored tool survey — every candidate seen, with its gate verdicts. Backs the Tools view; scoring happens later in solutions/matrix. Typically GENERATED from a richer research profile (not hand-maintained). Instance extensions narrow via allOf + $ref to this $id with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`_comment`	string	Free-text authoring/generation note; ignored by the kernel.
`tools` required	array<object>	The surveyed tools.
`name` required	string	Product name.
`vendor`	string	Vendor / maker.
`category`	string	Survey category (e.g. the L1/L2/L3 brief the tool came from).
`url`	string	Product URL.
`summary`	string	One-line characterisation of the tool.
`capabilities`	string	Free-text on what the tool covers natively vs. not.
`gates`	object	Gate verdicts, keyed by gate criterion id (→ requirements gate ids). Each is pass \| fail \| unknown. Key resolution checked semantically.
`tags`	array<string>	Short capability tags (e.g. 'Offene API', 'KI', 'WhatsApp').
`attrs`	object	Free-form attribute map — survey facets (hosting, DSGVO, pricing model, …) as label → value prose.

requirements.schema.json

requirements file

The SINGLE authored input to an engagement (Plan 15 drift ④: consolidates the former mission.json + criteria.json — ehimare led this and is canonical). Holds the business framing (purpose/useCases/stakeholders/stressTest/values/narrative) AND the scored criteria[] the kernel reads via ctx.data.requirements.criteria. Instance extensions narrow via allOf + $ref to this $id with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`_comment`	string	Free-text authoring note; ignored by the kernel.
`title` required	string	Document title — 'Anforderungen & Constraints — <client>'.
`statusBanner`	string	Optional Markdown banner flagging the document's confidence/status (e.g. model signed off, facts draft-to-verify).
`purpose` required	string	One paragraph: what the solution is FOR — the engagement's reason to exist, in business language.
`useCases`	array<object>	The jobs the solution must do, tool-neutral — these ARE the requirements in business language and seed the Fit criteria.
`id` required	string	Stable use-case key (referenced by criteria[].useCase and solution coverage maps).
`title` required	string	Short job name.
`what`	string	What the job is and why it matters — current pain included.
`currentState`	enum	How the job is handled today — drives the improvement story. `none` · `manual` · `digitized`
`improvementLevel`	enum	The kind of lift this job needs — from enabling something impossible today to layering an AI assist on a working baseline. `enable` · `digitize` · `improve` · `ai-assist`
`enables`	string	Optional note on what this job unlocks downstream.
`stakeholders`	array<object>	Who the solution serves and constrains — decider, daily users, the framing authority.
`role` required	string	The stakeholder's relationship to the solution (e.g. 'Decides & pays', 'Uses daily').
`who` required	string	Who fills that role, with the relevant context.
`stressTest`	string	The concrete scenario every candidate solution must survive — the worked case the whole comparison is sanity-checked against.
`values`	array<object>	The client's guiding values/principles, each tied to the criterion or gate that encodes it — the bridge from values to the scored model.
`value` required	string	The value/principle stated plainly.
`evidence`	string	Where the value is encoded in the model (which gate/criterion carries it) — keeps values and scoring honest.
`narrative`	object	The authored long-form framing (the 'why' prose) shown in the requirements view — a leitsatz plus titled Markdown sections.
`leitsatz`	string	The guiding sentence — the one-line thesis of the whole approach.
`sections`	array<object>	Ordered prose sections.
`h` required	string	Section heading.
`md` required	string	Section body as Markdown.
`criteria` required	array<object>	The scored model — gates, fit criteria and risk dimensions. The load-bearing array the kernel and shell read. Cross-references (useCase → useCases[].id, assistFor → another criterion id) are SHAPE-valid here and RESOLVED in the semantic tier.
`id` required	string	Stable criterion id (e.g. G-INDEP-01, F-CONTACTS-01, R-DATA-01); pattern conventions checked in the semantic tier.
`name` required	string	Short human name for the criterion.
`category` required	string	Which category/section the criterion belongs to (e.g. 'shared', 'system'); resolves against config.categories in multi-category instances.
`tier` required	enum	Importance tier. 'hard' marks a gate (pass/fail); the other three weight a Fit/Risk criterion via config.tierWeights. `hard` · `critical` · `standard` · `nice-to-have`
`axis` required	string	Which axis the criterion scores on — base vocabulary gate\|fit\|risk. Typed as string (not hard-enumed) so an extension may pin a widened axis set (e.g. skischule's 'curation'); the semantic tier enforces the instance's allowed axes.
`weight`	string,number	Numeric weight (often authored as a string). '0' for gates; the tier weight (e.g. '5'/'3'/'1') for fit/risk criteria.
`description` required	string	What the criterion measures and how its 1–5 scale reads — the rubric a scorer applies.
`useCase`	string	Optional link to the use case this fit criterion serves (→ useCases[].id).
`riskDim`	string	Risk dimension key — present only when axis:risk (e.g. datensicherheit, abhaengigkeit, resilienz, terminSicherheit).
`area`	string	Optional grouping label for display (e.g. 'Wissen', 'Technische Eigenschaften').
`appliesTo`	array<string>	Optional scoping — which categories/contexts the criterion applies to.
`assistFor`	string	For an optional AI-assist criterion: the id of the base (non-AI) criterion it augments — encodes the two-tier 'KI-free base + optional assist' model. Resolved in the semantic tier.
`costNote`	string	How cost/affordability is handled — typically a note that cost is neither a gate nor a fit score but a separate TCO comparison.
`notRequirements`	array<string>	Explicit non-goals — what was deliberately ruled OUT of scope, so the boundary is recorded.
`constraints`	object	Named hard constraints/context (compliance, budget, operating model, …) as free-form keyed prose — permissive map of constraint-area → description.
`openQuestions`	array<string>	Unresolved factual questions whose answers turn placeholder assumptions into real ones.

research-index.schema.json

research-index file

The append-only research ledger backing the Vertiefung → Bericht view — what was surveyed, round by round, plus the per-position/per-assist research state. Append-only `rounds[]` is what makes the iterative loop (Plan 15 MR-4) representable: new evidence is added, never overwritten. Instance extensions narrow via allOf + $ref to this $id with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`meta`	object	Header for the research view.
`title`	string	Title of the research cockpit/view.
`subtitle`	string	Optional subtitle.
`stand`	string	As-of date of the synthesis.
`note`	string	Synthesis note — what the research shows so far (no ranking, no winner).
`rounds` required	array<object>	The research rounds, in order — each a survey wave with what it looked at, what it found, and what shifted. Append-only.
`when` required	string	When/which round (e.g. 'Phase 3 · Runde 2 — Deep-Resurvey (2026-06-17)').
`focus`	string	What this round set out to survey.
`found`	string	What the round found.
`shifted`	string	What the round changed in the overall picture.
`findings`	array<object>	Structured findings the round produced — referenceable hypothesis/finding records (e.g. H1, S2).
`id` required	string	Finding id (referenced by architectures verdict.basis etc.).
`revisedIn`	string	Round in which the finding was last revised.
`note` required	string	The finding itself.
`positions`	array<object>	Per-architecture research state (proposition, confidence, standouts, open questions). Item shape is largely instance-specific (mirrors the architecture vocabulary); kept permissive here, pinned in an extension if needed.
`id`	string	Position id (aligns with the architecture it describes).
`name`	string	Position name.
`assists`	array<object>	Per-AI-assist research state (the ✨ assist questions and what the survey found about each). Item shape is instance-specific; kept permissive.
`id`	string	Assist id.
`label`	string	Assist label.
`researchFiles`	array<object>	The raw research artifacts linked as Rohmaterial from the Bericht view.
`label` required	string	Human label for the file.
`path` required	string	Path to the artifact (relative to the engagement).
`what`	string	What the file contains.
`meetingQuestions`	array<string>	The open questions to put to the client at the review — the research's distilled agenda.

solutions.schema.json

solutions file

Phase-4 candidate compositions — the filled, scored architectures. A solutions file is EITHER a bare array of solution objects (e.g. skischule's solutions-platform.json) OR an object wrapping them under `system` (demo/template/ehimare). Both shapes are blessed; pick whichever the instance ships. The per-solution shape is $defs/solution. Instance extensions narrow via allOf + $ref to this $id and add their own keys with unevaluatedProperties:false.

Feld	Typ	Beschreibung
`key` required	string	Stable selector for this solution (a `key`, not an `id` — see naming grammar D7).
`name` required	string	Display name of the solution.
`kind` required	string	Label on the buy↔build spectrum. RENDER-ONLY (no kernel logic branches on it) — so any non-empty string an instance's KIND_LABEL maps is valid (buy\|rent\|build, rent\|build, saas\|chatwoot\|eigenbau, …). No enforced enum.
`architecture`	string	The architectures.json `key` this solution fills; the board groups by it. Resolution checked semantically.
`shortlist`	number,null	Curation/ranking index, or null when rank is derived by the kernel.
`status`	enum	Board pill. Derived when absent (gate-fail→raus, all-offen→neu, else live). status:raus is also legal with no gate-0 (a decision-elimination). `live` · `offen` · `neu` · `raus`
`scores`	object	criterionId → score string. Gate = '0'/'1'; Fit/Risk = '1'–'5' (floats allowed). Key-resolution + range checked semantically.
`reasoning`	object	criterionId → 2–4 sentence note. A scored cell with no reasoning is flagged semantically.
`riskScores`	object	Hand-scored risk dims not derivable from criteria (e.g. abhaengigkeit, terminSicherheit) → 1–5.
`coverage`	object	Fit-criterion id → coverageCode. The composition, keyed by use case.
`knowledge`	→ knowledge	The per-facet confidence grid for this solution (spezif/kosten/effort/risiko/fit).
`spezif`	→ knowledgeState	Confidence that the solution is properly DEFINED — e.g. that its filler set is pinned. Distinct from fit: a solution can be under-defined precisely when you don't yet know which fillers it needs. `offen` · `geschätzt` · `bekannt`
`kosten`	→ knowledgeState	Confidence in the cost estimate. `offen` · `geschätzt` · `bekannt`
`effort`	→ knowledgeState	Confidence in the build + maintenance effort estimate (Plan 15 MR-2: renamed from the former `build`). `offen` · `geschätzt` · `bekannt`
`risiko`	→ knowledgeState	Confidence in the risk assessment. `offen` · `geschätzt` · `bekannt`
`fit`	→ knowledgeState	Confidence in the fit scoring. `offen` · `geschätzt` · `bekannt`
`costInputs`	object	Generic cost inputs (setup, recurringYr, basis?, …) priced under the Scenario. Instances with a richer cost engine (skischule's typed costModel) carry it in their extension schema instead.
`workPackages`	array<object>	Build/integration packages. Count each once per solution; never sum across solutions.
`name` required	string	Name of the work package.
`covers`	array<string>	Use-case/criterion ids this package delivers; resolved semantically.
`effort` required	→ effortBand	The optimistic/expected/pessimistic person-day band for this package.
`opt` required	number	Optimistic person-day estimate (best case).
`exp` required	number	Expected person-day estimate (most likely).
`pess` required	number	Pessimistic person-day estimate (worst case).
`maintHrsMo`	number	Maintenance hours/month → Cost bucket ②.
`recommended`	boolean	The AUTHORED verdict — is this the favoured solution. Register-1/2, never encoded in shell copy.
`verdictNote`	string	One-line why, shown as the lead. Pairs with recommended.
`tradeoff`	string	What you give up — one line.
`narrative`	string	How the solution actually works — descriptive prose (register-2).
`revisedIn`	string	Round marker (e.g. 'R2') of this solution's last material change — feeds staleness().
`qualitative`	object	PERMISSIVE per-project container (Plan 15, Decision 2). Any instance-specific qualitative block lives here — skischule's {verdict,strengths,weaknesses,risks,fit}, ehimare's redTeam[], etc. The base asserts only 'it is an object'; an instance extension MAY pin its keys. Solution-level prose that is genuinely common (narrative/tradeoff/verdictNote) stays as named fields above; everything bespoke goes in here rather than breeding half-used named slots.

Pro Instanz

Erweiterungen

Jede Engagement erweitert die Basis-Schemas um eigene Felder (allOf + unevaluatedProperties: false) — die Felder unten kommen zusätzlich zur jeweiligen Basis.

ehimare

ext/ehimare/solutions.schema.json — Per-instance extension for the ehimare engagement's solutions file — a Plan 15 TARGET-SPEC. It describes the shape ehimare carries AFTER it re-pins to the clean core and migrates (forks→prune, knowledge.build→effort, and drops the retired facetForks/liveFillerForks). It composes the generic base solution ($ref) and adds ehimare's bespoke fields; unevaluatedProperties:false then REJECTS any field neither the base nor this extension documents — so a stale legacy key surfaces as an error and the migration knows exactly what to strip. Not validated until ehimare bumps the pin; that is the customer's own work (§ Completion criterion — instances re-pin on their own schedule).

Feld	Typ	Beschreibung
`integration`	object	The ehimare-specific 6th facet (deliberately OUTSIDE the generic 5-facet `knowledge` block): how the solution's core tool docks the KI-Schicht. Phase 0 named this the engagement's signature divergence.
`dock` required	string	Docking posture of the core tool's integration surface (e.g. 'open' = open API present).
`api`	string	What the integration surface is, in prose (e.g. 'REST + Webhooks').
`method`	string	The integration method/transport, as an instance-defined keyword (e.g. 'rest').
`confidence`	→ knowledgeState · solutions	Trust in the integration assessment — reuses the generic offen\|geschätzt\|bekannt confidence scale.
`coreTool`	object	The anchor product the composition is built around — the one tool that carries the spine, onto which the fillers dock.
`name` required	string	Core tool product name.
`what`	string	One-paragraph characterisation of the core tool and how it serves as the spine.
`url`	string	Core tool product URL.
`tools`	array<string>	The named products that make up this composition (core tool + fillers), as display strings.
`narrativeDelta`	string	What the latest research round CHANGED about this solution — the round-over-round delta shown beside the narrative; pairs with revisedIn.
`redTeam`	array<object>	The adversarial log — ehimare's bespoke structured prose register (Decision 2): each entry a claim, the challenge raised against it, and how it resolved.
`claim` required	string	The asserted strength/fact under test.
`challenge` required	string	The objection raised against the claim.
`resolution` required	string	How the challenge resolved (confirmed/revised), with the evidence.

skischule

ext/skischule/solutions.schema.json — Per-instance extension for the skischule engagement's solutions file (solutions-platform.json) — a Plan 15 TARGET-SPEC. skischule's signature divergence is its typed COST ENGINE (seasonal seats · annual discount · peak weeks · the Chatwoot configurator), which the generic base deliberately does not model. This composes the base solution ($ref) and adds the cost-engine fields; unevaluatedProperties:false rejects anything neither the base nor this extension documents. The cost-component shape is skischule-internal and refined when skischule actually re-pins and migrates — not validated until then (§ Completion criterion).

Feld	Typ	Beschreibung
`costModel`	object	The typed cost engine for this solution (replaces the generic costInputs). Priced under the shared Scenario by skischule's inline cost(sol, scenario) hook, never by the kernel.
`annualDisc`	number	Fractional discount applied to annual (vs monthly) billing, e.g. 0.18 = 18% off.
`components` required	array<oneOf>	The priced lines of the model — seats, AI seats, metered usage, one-offs, flat ranges.
`type` required	—	Discriminator: a flat-range (tiered) charge.
`ratePerSeatMo` required	number	Monthly rate per seat.
`label`	string	Display label for the cost line.
`aiSeatFactor`	number	How many AI seats per human seat (e.g. 1 = one Copilot per user).
`ratePerAiSeatMo` required	number	Monthly rate per AI seat.
`demandVar`	string	Name of the scenario demand variable that drives the meter (e.g. 'C_mo').
`mode`	string	How usage is billed — e.g. 'block' (priced per fixed block) vs per-unit.
`blockSize`	number	Units per billing block when mode='block'.
`ratePerUnit` required	number	Price per unit (or per block).
`included`	number	Units included before metering starts.
`peak`	boolean	Whether this line is driven by peak-week demand (the seasonal spike).
`amount` required	number	The one-off amount.
`bucket`	string	The chosen tier/bucket name this charge corresponds to.
`perMo` required	number	Flat monthly amount for the chosen bucket.
`variants`	array<object>	The Chatwoot configurator's selectable build variants — each a hosting choice plus a per-assist selection that re-prices and re-scores the solution.
`key` required	string	Stable variant selector.
`name`	string	Display name of the variant.
`hosting`	string	Hosting choice for this variant (e.g. 'cloud' \| 'selfhost') — keys scoreDeltas.hosting.
`sel`	object	Per-assist selection map (assist label → chosen build mode, e.g. 'sidecar' \| 'captain').
`scoreDeltas`	object	Additive Fit adjustments (clamped 1–5) applied on top of the base scores depending on a configurator choice — chiefly per-hosting.
`_note`	string	Authoring note explaining the deltas; ignored by the kernel.
`hosting`	object	hosting value → { criterionId → additive delta } applied when that hosting is selected.
`pricing`	object	The surveyed list pricing for the solution's core product — provenance for the cost model (what the vendor actually charges).
`tier`	string	Human summary of the relevant pricing tiers.
`monthly`	string	The monthly figure or range used.
`verified`	boolean	Whether the pricing was confirmed against the vendor (vs estimated).
`notes`	string	Detail on the tiers, caps, and caveats behind the figure.
`risk`	object	Named risk-dimension prose (dimension → note) — skischule's authored risk commentary alongside the numeric riskScores.
`buildNarrative`	string	How the build/configuration of this solution actually works — the eigenbau/Chatwoot assembly story.