How RiskAlign uses AI — and the evidence boundary
Current RiskAlign source contains Compass AI assistance for bounded draft tasks. Those drafts are separate from human disposition and do not themselves make or publish a governance decision. Whether a particular deployed environment has Compass enabled, correctly configured and successfully executing through its provider is a runtime matter and must be evidenced separately from source code.
Implemented Compass AI surfaces
- Compass risk categorisation
Suggests one best-fit category from the tenant's recorded risk-category list, with confidence and supporting reasons.
Human control: The model output is stored as a draft suggestion. A human remains responsible for any governed category decision or saved record state.
- Compass board-narrative draft
Drafts a concise three-sentence narrative from the selected risk's recorded facts and description.
Human control: The draft is stored in the Compass review queue. A named authenticated user can ratify it, override it with a reason, or dismiss it with a reason.
Authority boundaries
- The current Compass prompt contract does not give the model authority to make a final risk-category determination.
- A Compass narrative is generated as a draft rather than being automatically published as a board or governance record.
- Human ratification, override or dismissal remains a separate recorded action from the model call.
- Source presence alone does not establish that AI is enabled, configured or operating in a deployed environment.
Source-implemented controls
- The current source records an agent_runs entry around each model call, including model/prompt identifiers and hashes, input/output hashes where available, token counts, latency, gateway run id, surface and failure status.
- Compass outputs are stored in compass_suggestions as draft suggestions before human disposition.
- Ratification, override and dismissal update the suggestion record with the human actor and timestamp; override and dismissal require a reason.
- User-supplied text is sanitised, length-capped and wrapped in explicit untrusted delimiters before the current model-call paths.
- The current model-call path depends on LOVABLE_API_KEY. If configuration is missing or the gateway call fails, the source records an error state and returns a visible error rather than silently treating the call as successful.
- The current Compass AI call path does not implement a deterministic fallback for an unavailable gateway; any broader degraded-mode capability must be evidenced separately before it is claimed.
- Deployment configuration, actual provider execution, provider contractual terms, data residency/egress and operating effectiveness remain runtime/release evidence questions rather than source-code assumptions.
Evidence boundary
These source controls can support AI-governance evidence, but source implementation is not proof of legal classification, regulatory compliance, deployed configuration, provider terms, data residency, live tenant isolation, successful provider execution or operating effectiveness. Those matters require the applicable runtime, contractual, privacy, security and release evidence before they are represented externally.
See also: Trust Centre, Compass methodology, Security Roadmap, Vulnerability Disclosure Policy, Known Limitations.