Governance Architecture & Technical Specs

Tenants define their own compliance framework records, tagged by type — SOX, GDPR, HIPAA, PCI-DSS, SOC2, ISO 27001, or Custom — with the framework's own requirements supplied as structured data. Aeion ships built-in control templates for the standard frameworks and gives you the record model plus a set of automated checks, so you can seed from a template or define a framework of your own.

Automated Control Checks:

Each requirement can attach one or more control checks. Built-in check types verify an audit trail exists for a resource, that a resource is encrypted at rest, and that access logs don't show a pattern of denied-access attempts — each failure produces a finding with a severity (critical/high/medium/low), a description, and a remediation suggestion.

Compliance Status Roll-Up:

Findings roll up into a per-resource compliance status — compliant, at-risk, or non-compliant — based on finding severity and count (any critical finding makes a resource non-compliant; multiple high-severity findings mark it at-risk). Reports aggregate pass/fail/warning counts for a framework over a date range, plus generated remediation recommendations for each failing requirement.

Evaluates approval policies against every incoming request and drives a time-based escalation queue when nobody acts in time.

Policy Evaluation:

Each policy has a priority (lower wins), a set of match conditions (field, operator, value — equals/notEquals/contains/greaterThan/lessThan/in/notIn), an approver configuration (a specific user, a role, a group, or a dynamically computed approver), an escalation timeout in hours, and an optional unanimous-approval requirement.

Escalation Queue:

Requests are evaluated against enabled policies sorted by priority; the first policy whose conditions all match determines the approver set. If a request sits pending past its policy's escalation timeout, it's automatically marked escalated and a notification fires — no request silently expires because nobody happened to check.

Delegation Handling:

Before routing a decision to an approver, the workflow checks whether that approver has an active delegation on file. If so, the decision is redirected to the delegate automatically, so a manager on vacation doesn't become a bottleneck.

Manages data retention rules with an archive-before-delete guarantee.

Policy Structure:

A retention policy names the target collection, a set of match conditions (field, operator, value) that identify eligible records, a retention period (a duration plus years/months/days unit), whether to archive before deleting, and where the archive should land.

Archive Before Delete:

When a policy runs, it first finds every record that's past its retention period. If archiving is enabled, each expired record is written to cold storage before anything is removed from the live database — the archive location is recorded against the job, and deletion only proceeds for records that archived successfully. Nothing is deleted without a successful archive first.

Tenant-Scoped Evaluation:

Policies are evaluated per tenant, so one tenant's retention rules never touch another tenant's data — each policy produces its own job with its own results.

Job Tracking:

Every run produces a job with a status (pending → processing → completed/failed), counts of records processed/archived/deleted/failed, start and completion timestamps, and a per-record action log — so you can always answer "what exactly happened to this record and when."

Manages fine-grained access policies with priority evaluation.

Policy Structure:

A policy names the subjects it applies to (specific users, a role, or a group), the resource types and actions it covers (e.g. "orders" + "read"/"write"/"delete"), an optional set of match conditions, a priority, and an effect — allow or deny.

Priority-Based Evaluation:

Policies are evaluated in priority order (lowest number first). The first policy whose subjects, resource, action, and conditions all match wins and its effect (allow or deny) is applied — so a specific, high-priority deny can override a broader, lower-priority allow.

Time-Based Access:

Conditions can include a time window — a start time, end time, and specific days of the week — so a policy can, for example, restrict access to a resource outside business hours.