Thank you so much for this feedback — it really means a lot!
Yes, exactly: the goal is to make the governance layer fully explicit, auditable, and version-controlled instead of burying it inside prompts (where it's fragile, non-deterministic, and very jailbreak-prone).
Regarding your question about plugging in a domain-specific rules engine (medical workflows, financial processes, etc.):
The current architecture (detailed in EL-ARCH.md) is designed with *modularity in mind* right from the start.
The Governance Layer is meant to be:
- event-driven (receives standardized observations via Pydantic models)
- pluggable: applies a sequence of validators / rule-checks
- decision-oriented: returns ALLOW, DENY (with justification), or DELEGATE_WITH_CONSTRAINTS
So in theory, integrating a domain-specific engine should be reasonably straightforward:
1. Write a thin adapter that maps Elia events/facts → input format of the target engine
2. Translate the engine's output back into Elia decisions (ALLOW/DENY + explanation)
3. Register it as one of the rule modules in the Governance pipeline (via config or factory)
Examples of realistic integrations:
- Simple Python functions or small rule sets → very easy (days)
- Open Policy Agent (OPA), Rego policies → medium (1–3 weeks, mainly mapping + error handling)
- Drools, a lightweight Prolog-like, or even a small custom knowledge base → medium to hard depending on complexity
- Certified medical/financial rule engines → significantly harder (semantic mapping + validation/certification overhead)
For a medical workflow example (e.g. assisted prescription or diagnosis support):
- Rules could cover contraindications, max dosage, drug interactions, patient consent / GDPR/HIPAA constraints
- A combination of OPA + a SQLite-based drug DB or external API would already cover a lot of ground
Right now this is still at the *specification + high-level diagram stage* — Phase 0 (a minimal in-process skeleton) is planned but not started yet. I'm primarily an architect, not a full-time implementer, so concrete extensions like this would benefit enormously from collaboration.
Do you already have a preferred rules engine / policy language / framework in mind for your day-to-day work?
Knowing that would help a lot in prioritizing extensibility points in the spec and the upcoming Phase 0 prototype.
Thanks again — comments like yours are exactly why I shared this early!