Near-term (active backlog)
Custom dashboard builder
A drag-and-drop dashboard composer where operators pick widgets (KPI card, time-series chart, table, heatmap) from a palette and bind each to a data source. Today’s dashboards are fixed, config-driven pages; there is no Dashboard entity in the data model. This also unblocks thedashboard share-link kind (see below) and closes the loop started by
the dashboard Export and Save as Report affordances — any
custom dashboard instantly becomes a scheduled report.
dashboard share-link kind
Public share links shipped for report runs and decision traces
(/api/v1/public/shares/[token]), but the dashboard kind currently
resolves to nothing because dashboards aren’t persisted entities.
Either wire it to the dashboard builder above or remove the option
from the share dialog until then.
Slack / Teams click round-trip in production
Interactive buttons render in both adapters and the HMAC-verified callback receiver is live (/api/v1/notifications/interactions), but
completing the loop requires registering a Slack App (for
X-Slack-Signature callbacks) or a Teams Workflow per deployment.
This is operator configuration, not code — a setup runbook per
provider is the remaining work.
Operational error tracking for background workers
The outbox publisher and background workers log failures via the structured logger only. Adopting the error-tracking pattern (Sentry-style capture with correlationerrorIds surfaced in
responses) across worker paths is queued.
Mid-term
Scheduled screenshot-style dashboard PDFs
Current exports are data-driven — the runner regenerates the report from the underlying data sources at run time. Complement this with layout-capture PDFs that mirror the dashboard’s rendered UI pixel-for-pixel. Useful for executive packs where the rendered visualisation is the deliverable.Python-native GBM training
Weight-of-evidence binning and target encoding run TypeScript-side and bridge into gradient-boosted training. A Python-native trainer would simplify large-dataset training on the ml-worker, at the cost of maintaining the preprocessing logic twice — deferred until dataset sizes demand it.CDK modules
Terraform modules for EventBridge and App Runner shipped (terraform/modules/). CDK equivalents are queued for teams that
standardise on CDK.
Horizontal scaling for AI mutation previews
The AI assistant’s preview→approve flow stores pending mutations in process memory, which is correct on the current single-instance deployment. Scaling the API tier horizontally requires moving the pending-mutation store to Redis so an approval can land on any instance.Parked / future
Intentionally deferred. Listed so there’s no ambiguity about what we’re not working on — if any of these become a hard blocker for a pilot, let us know and we’ll re-prioritise.Mobile SDKs
Native iOS / Android SDKs for client-side Recommend + Respond. Parked until we see meaningful pull from mobile-first pilots; the REST APIs are fully usable from native HTTP clients today (Python, TypeScript, CLI, and Postman collections ship insdks/).
Shared read-only demo tenant
A single always-on tenant with pre-loaded decisioning scenarios so prospective users can evaluate the platform without creating an account. Parked until user volume onplayground.kaireonai.com makes
the read-only sandbox cost-effective to maintain.
Full i18n rollout
The i18n foundation is in place — locale message catalogues (en, hi) plus the next-intl configuration — but per-page wiring has not started: no page currently calls the translation hooks. Parked until we have an identified non-English pilot; the effort is mechanical but sizeable.Repository splits: kaireon-py and decisioning-bench
The Python SDK (platform/integrations/python/) and the open
decisioning benchmark (tools/qa/decisioning-bench/) are planned to
graduate to their own repositories (with PyPI / GitHub Pages
publishing respectively) as part of the open-source launch. They
remain in-repo until then.