SAFETY & GOVERNANCE

Delegated work you can audit.

Bounded scope, stated limitations, human oversight at every step, and a complete record of what happened. No black boxes.

THE DIGNITY PRINCIPLE
“At all times, the output of all work must respect the dignity of direct and indirect users. Such dignity is centred around universal and absolute respect for the individual.”
Almma Dignity Principle Written before the first delegation shipped. It governs every one since.

AI should serve people, not replace human judgment where it matters most. Real operational work can be delegated — but only inside boundaries a person has defined and signed off, which is why every delegation is written with its limitations, not just its capabilities.

This isn’t a constraint on what the software can do. It’s the foundation of the trust that makes delegation possible at all — and the reason accountability stays with a named person rather than moving to a system.

Core safety principles

Five properties that hold for every delegation, stated before anything runs.

Explicit non-responsibilities

Every delegation is written with what it will not do, alongside what it will. Boundaries are agreed at design time, not discovered after an incident.

Human override by design

Authorized people can intervene at any point. Escalation paths are built in from the start, not added as an afterthought.

Complete auditability

Every action, decision, and escalation is logged — for compliance, for review, and for making the next delegation tighter.

Task-scoped memory

Each delegation holds only the context of the work it was given. No general-purpose drift, no unauthorized expansion of scope.

Ongoing assurance

Standardized resiliency testing against known attack vectors on every upstream release, returned as an evidence pack your auditors can read. Upstream now ships continuously; the re-test surface grows with it.

Controls against fabrication

No one can guarantee that a language model never invents an answer, and we won’t claim it. What we can do is design the delegation so that a fabricated answer has nowhere to go — and so that low confidence produces an escalation instead of a guess.

These are engineering commitments and configured controls, not properties of the model.

DESIGN COMMITMENTS
Grounded answers with citations
Responses referencing your data or policies must carry the source. Answers that can’t be grounded are not returned.
Confidence thresholds
Each delegation is configured with a floor. Below it, the work routes to a person rather than producing an answer.
Estimates marked as estimates
Where an approximation is produced, the reasoning is shown and the output is labelled — never presented as a determination.
Escalation on uncertainty
Ambiguity and out-of-scope requests are exit conditions by design, and each one is logged for review.
HUMAN OVERSIGHT FRAMEWORK

Four layers of control

Oversight isn’t a switch you flip in an emergency. It’s four mechanisms, configured per delegation, that keep a person in the loop at different time scales.

01
Real-time intervention
Authorized people can take over an interaction at any moment. Control returns to the human immediately, mid-task.
Live chat takeover Ticket reassignment Process interruption
02
Escalation triggers
Predefined conditions route work to a named reviewer automatically. Triggers are set per organization and per task type.
High-value transactions Sensitive topics Low confidence
03
Approval workflows
Consequential actions require human sign-off before execution. Nothing consequential happens without explicit authorization.
Report submission External communications System changes
04
Continuous review
Regular audits of performance, escalation patterns, and edge cases. Boundaries get refined against real-world data.
Performance review Escalation analysis Boundary refinement

Complete auditability

Every action logged. Every decision traceable. No black boxes.

Action logs
Every task performed, response generated, and decision made — recorded with timestamps.
Decision traces
The reasoning path: what data was considered, which rules applied, and why this output rather than another.
Escalation records
Full context preserved at handoff: why it escalated, to whom, and what happened next.
WHAT GETS LOGGED
Input received, with PII handled per policy
Data sources accessed
Rules and policies applied
Output generated
Confidence level
Escalation triggers, if any
Human interventions
Outcome and resolution

Data security & privacy

How data is handled in a deployment. Where a control is configured per deployment rather than held today, it says so.

Data protection
Encryption in transit and at rest
Deployment on infrastructure you control or approve
Incident response procedure agreed at scoping
Access control
Role-based access control (RBAC)
Minimum-privilege data access
SSO and MFA support
Session management and timeout controls
Privacy by design
PII identification and handling policies
Data minimization — only the access the task needs
Configurable retention policies
Export and deletion capabilities
Data residency
Region-specific storage options
Customer-controlled data location
Clear data processing agreements
No training on your data — model providers configured with training disabled, stated per deployment.

Compliance requirements we design for

We hold no certifications today and we won’t imply otherwise. What we do is treat your regulatory obligations as design inputs: the diagnosis engagement establishes which frameworks apply to the work being delegated, what each one requires of the deployment, and what evidence you’ll need to produce.

Where a framework requires an agreement or an audit we can’t sign today, that’s stated in the scoping document rather than discovered in procurement.

Talk to us about your compliance requirements →
FRAMEWORK ADDRESSED IN DIAGNOSIS
SOC 2
Control mapping for the deployment. No Type I or Type II report exists yet — if you need one, we’ll say so before you spend time on the questionnaire.
GDPR
Lawful basis, data minimization, residency, retention, and deletion built into the delegation design. DPA reviewed per engagement.
CCPA
Consumer data handling and deletion obligations identified for the specific work in scope.
FERPA
Student-record handling assessed against the delegation before any student data is in scope. No documented institutional posture yet — expect to build it with us.
HIPAA
We do not sign a BAA today and don’t take PHI in scope. If your work requires it, we’ll tell you at the first conversation.
WHO YOU ACTUALLY WORK WITH

YOU WORK DIRECTLY WITH THE PEOPLE WHO BUILD AND MAINTAIN YOUR DEPLOYMENT

There is no account team and no tier you get routed through. The founder scopes your delegation boundaries; a dedicated engineering team — including a security specialist — builds and maintains the deployment. The scope is small on purpose, and the commitments are the ones that can actually be kept.

Direct access, not a queue
One point of contact who knows your deployment because he built it. Response commitments are agreed in writing at scoping — realistic ones, for a company of this size.
Ongoing refinement
Regular review of how the delegation is performing, where it escalates, and which boundaries should move. Improvements carry forward with your deployment.
Stated limits on capacity
A small number of engagements at a time. If we can’t support your deployment properly, that’s a conversation before a contract, not after.

Questions about safety & governance?

We’ll walk through the approach in detail — including security documentation, what we hold today, and the deployment architecture.