Just in time adaptation intervention platform

[Hsankesara]

Title: RFC NNNN:

Summary

Generic Just in time adaptation intervention platform aims to create a generic and scalable architecture to implement custom interventions drive by configs.

Checklist

• Linked pre-RFC discussion issue
• Used file name rfcs/NNNN-title.md and updated RFC front matter
• Filled all required sections (Summary, Motivation, Design, Security, Migration, Testing)
• Added to index table in README.md
• Considered alternatives and documented open questions
• Applied appropriate status label (one of: draft, accepted, rejected, superseded, implemented)
• Applied area/type labels as relevant (e.g., platform, backend, mobile, data-analytics, general, privacy; design, process)

Reviewers

@yatharthranjan @mpgxvii @pvannierop @afolarin

[yatharthranjan]

The link path looks incorrect (rfcs/platform.0002-... uses a dot). Should this point to rfcs/platform/0002-just-in-time-intervention-platform.md so the index entry is clickable?

[yatharthranjan]

This YAML block appears over-indented under - type: "send_notification", which may make the example invalid for readers. Could we align output_key, value_condition, and value with type?

[yatharthranjan]

Quick metadata check: is the GitHub handle in Author(s) intended to be @Hsankesara? It currently reads @hsankesata.

[yatharthranjan]

Thanks Heet, really good to see this come to life.
I believe this RFC may be a bit outdated now, and you have progressed with some changes that might already answer some of the questions raised here.
Please update the RFC wherever it has drifted from current plans/implementation.

---

Security & Privacy

Do we need any further controls here, such as:

1. workload isolation boundary (namespace/pod/runtime policy),
2. least-privilege IAM per intervention/job,
3. secrets management/rotation approach,
4. network egress restrictions,
5. artefact provenance (signing/SBOM),
6. data-access boundaries per intervention (dataset/table/subject scope)?

Flink/Spark

I don’t think Flink uses Spark in the backend. Please double-check and fix if necessary.
Perhaps we also need to revisit any design rationale derived from this (especially integration assumptions with radarpipeline and connector strategy).

Airflow vs NiFi

What are the architectural responsibility boundaries between Airflow and NiFi?
Is Airflow only the control/orchestration plane and NiFi only the action delivery/execution plane, or do both schedule/execute intervention logic?
Currently, there may be an overlap.

State Model

Is per-participant intervention state explicitly modelled anywhere?
It might be useful to store participant-level state such as cooldown windows, prior exposures, suppression windows, escalation history, and “already-notified” markers.
I presume, if needed, these would be stored in either Kafka or a feature DB?

Correctness & Safety

Some suggestions for intervention correctness and clinical safety:

1. decision policy framework (eligibility, suppression/cooldown, escalation, personalisation, guardrails),
2. evaluation methodology (e.g., A/B or stepped-wedge approach, outcome definitions, causal validity concerns),
3. safety controls (kill switch / global pause, rollback strategy, operator override).