A-04 — Starter Packs for Administrators
Scope: Enabling a starter pack in deployment — what must be ready before you switch a pack on, how activation and rollback work, and how you recognise failure early (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md; source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md; source: A-01 — Jijibora Deployment (Administrator Operations); source: docs/commercialization/playbooks/dictionary.v1.json) Status: as of 2026-11-09 Blueprint sources: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md; docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md; A-01 — Jijibora Deployment (Administrator Operations); docs/commercialization/playbooks/dictionary.v1.json; datasets/lookups/lookup.finmon.cohort_billing.v1.json
What this means for you
Enabling a starter pack is turning on configuration, not shipping code. Each pack carries its own lookup keys and scenario definitions, and the runtime reads them as values from the lookup store (source: docs/commercialization/playbooks/dictionary.v1.json). You always land in Soft posture first. Soft means practice run on the same path with zero live writes; a pack cannot declare itself live (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). Rollback is a re-pin, not a redeploy. Because activation is declarative, reverting means pinning back the previously approved configuration values (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md).
Details
1. Enablement checklist (config + pipeline + identity)
Do not open the pilot until all three groups below are green. On any doubt, refuse the switch-on (source: A-01 — Jijibora Deployment (Administrator Operations)).
Config readiness
- Tenant is provisioned through the commercial path (
POST /v1/admin/tenants/provisioninafrica/community_os); shelling namespace creation is not the commercial path (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). - Pack lookups and scenario packs are loaded from the declared keys for the chosen pack — for example the community starter binds
lookup.jijibora.community.starter.v1andscenario.jijibora.community.starter.v1, and the claims motor pack binds nine claims lookups plusscenario.claims.motor_ke.v1(source: docs/commercialization/playbooks/dictionary.v1.json). - Policy/threshold values sit in lookups, not in code. Guard bands, evidence requirements, and approval thresholds change without a code change (source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).
Pipeline readiness
- Outbox relay is live and pending depth falls to zero and stays there; the durable anchor is
nats_outboxwith rows flowing pending to sent to delivered or failed to dead-letter (source: A-01 — Jijibora Deployment (Administrator Operations)). - Kestra, Camel, and Solver Gateway are reachable for the stages the pack needs. Sourcing packs need the solver; if it is down the pack must refuse with 503 and never return a synthetic optimal answer (source: A-01 — Jijibora Deployment (Administrator Operations)).
- Soft wiring is proven end to end first: outbox row written for the pack's emit, consumer acknowledges, and the Soft acceptance test for the pack passes (source: docs/commercialization/playbooks/dictionary.v1.json).
Identity readiness
- Keycloak realm-per-tenant is up; down means login and session fail closed (source: A-01 — Jijibora Deployment (Administrator Operations)).
- APF roles and tenant scope (
scope:<community>) are in place, with break-glass configured for dual approval with time-to-live and audit (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md). - Secrets resolve from the vault and production-readiness is green before go-live; if any check is ambiguous, refuse go-live and stay in Soft (source: A-01 — Jijibora Deployment (Administrator Operations)).
2. Pack activation mechanics
- A pack is bound by reference: lookup keys, scenario pack, CNS claim types, and consumer wiring are named in the dictionary pack entry, and the runtime resolves them as values (source: docs/commercialization/playbooks/dictionary.v1.json).
- Changing a lookup value (threshold, SLA band, evidence list, panel roster) re-seeds the lookup store. Runtime services read from the store, never from filesystem paths, so a lookup change takes effect without a code rebuild (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md).
- The monetization reference is also declarative: the dictionary SKU entry names the offer package, subscription plan, and revenue split profile, and cohort billing pins a
billing_refto one of the four allowlisted offer-package ids (source: datasets/lookups/lookup.finmon.cohort_billing.v1.json; source: docs/commercialization/playbooks/dictionary.v1.json).
3. Rollback behaviour (soft pins)
- Soft activation goes through a soft pin:
putSpecSoftPinrequires anapproved_digestand recomputes it from the candidate document (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). - A missing or mismatched digest returns
pin_mismatchand writes nothing to the store. NATS being down returnsnats_kv_unavailableand also writes nothing (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). - Therefore what you can revert by lookup alone: any pack change that only altered lookup/scenario values. Re-pin the previously approved digest and the values revert, with no deploy and no schema change (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md).
- What you cannot revert by lookup alone: anything that required a schema change or new code, which should not exist in a well-formed pack — if the change needed a new table, stop and escalate instead of rolling forward (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).
4. Pilot-vs-LIVE gating ritual
Run the ritual in this order, with a rollback rehearsal between Soft and LIVE:
- Soft posture first. Land the pack on the Soft path: outbox plus allowlisted subject, zero live writes, Soft banner on every surface that touches money, custody, or uptime (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: A-01 — Jijibora Deployment (Administrator Operations)).
- Rollback rehearsal. Re-pin the previous approved digest in Soft and prove the revert lands cleanly before any LIVE talk. A pack that cannot roll back in Soft does not advance (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md).
- LIVE gate flips only on real checks. LIVE means the JetStream path with the ceiling enforced. Nothing sets live-met without real probe results, env flags alone never count, and a pack cannot self-declare live (source: docs/platform-map/jijibora/D-02-PLAYBOOK-DESIGNS.md; source: Playbook Registry — What You Can Run, Who Runs It, What You Get Back).
- Pilot vs LIVE in operations. In pilot posture, payments are sandbox-only with manual reconciliation and no auto-debit promise. The banner clears only when the same gates that made Soft necessary are closed and the owner re-signs the go-live gate (source: A-01 — Jijibora Deployment (Administrator Operations)).
5. Failure signatures per component
Signatures below are the operator's first read. On any of them, fail closed — never substitute a synthetic success (source: A-01 — Jijibora Deployment (Administrator Operations)).
| Component | Signature you see | Meaning / refuse rule |
|---|---|---|
| Config pin | pin_mismatch, no store write | Candidate digest absent or one bit off. Refuse; do not force the put (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). |
| Lookup store | nats_kv_unavailable | Store unreachable. Refuse the pin; do not fall back to disk reads (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). |
| Policy root | policy_root_unconfigured | LIVE put needs a customer key + signature; missing either refuses. No vendor vault fallback is written (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). |
| Tenant provisioning | provisioning that shells namespace DDL | Not the commercial path. Use POST /v1/admin/tenants/provision; until automation ships, offer white-glove onboarding (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). |
| Payments | sandbox key presented as live | A sandbox key is never reported as live. Manual reconciliation until live cutover (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md). |
| Outbox relay | pending depth never falls to zero; relay error every cycle | Follow the relay runbook; never mark rows delivered by hand (source: A-01 — Jijibora Deployment (Administrator Operations)). |
| Solver | 503 on sourcing solves | Solver gateway down. Refuse the solve; never return a synthetic optimal answer (source: A-01 — Jijibora Deployment (Administrator Operations)). |
| Identity / secrets | login or secret resolution refused | Keycloak or vault down. Fail closed at the door (source: A-01 — Jijibora Deployment (Administrator Operations)). |
Open items / gaps
- Live payment cutover, automated tenant provisioning, and multi-file store with supported high availability remain open; until they close, the Soft banner stays and manual reconciliation continues (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md; source: A-01 — Jijibora Deployment (Administrator Operations)).
- Customer-held policy root signing and customer-key evidence signing are not the live path today; the vault is vendor-operated (source: A-01 — Jijibora Deployment (Administrator Operations)).
- Exact revert procedure for CNS catalog entries and APF vocabulary edits is UNKNOWN in this read set — treat as lookup-only revert and escalate anything wider (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).
- Telemetry and alerting are configured but full alert wiring and status page are roadmap, not live (source: docs/jijibora-gtm/09_GAP_ANALYSIS_AND_RECOMMENDATIONS.md).