Trust & security
Governed work you can read line by line.
EQ workers act inside your rules, check their own output, and record every step. This page is the product in ledger form — supervision, rule versioning, data boundaries, models, and where we are on compliance.
Governance
How a worker is supervised.
Nothing runs on trust alone. Each worker has a supervision level, a sign-off gate on sensitive actions, an undo, and an append-only log.
- Supervised
- Every result is checked against your rules before it counts. Confidence below threshold is raised, never guessed.
- Sign-off gate
- Defined actions (pay runs, exceptions over a cap) wait for a named human approval before they proceed.
- Undo
- Any action a worker takes can be reversed from the log — no database surgery, no support ticket.
- Attribution
- Every entry records which worker, which rule, which version, and who signed off.
Activity log — sanitized sample
Append-only- 09:14:14Timecard #4821 validated against schedule· R2passed
- 09:14:11Payroll run — 3 exceptions raised for sign-off· R11flagged
- 09:14:08Onboarding — credential verified for J. Rivera· R4passed
- 09:14:0562 hrs exceeds cap — raised to supervisor· R7flagged
- 09:14:02Bill record reconciled — client Anders Group· R2passed
Every action is logged, attributed, and reversible. Nothing happens off the record.
Rules
Your rules, versioned.
Rules are not buried in a prompt. They are named, versioned artifacts with a change history you own — and every worker action cites the rule it applied.
- Rule IDs
- Each rule has a stable ID (R7, R11). When a worker flags something, it cites the rule — “62 hrs exceeds cap · R7”.
- Change history
- Rule sets are versioned (v14, v15). Every change is logged with author, timestamp, and diff.
- Golden-set testing
- Before a rule change goes live, it runs against a saved set of known-answer cases. If an expected result changes, the update is held for review.
- Rollback
- Revert to any prior rule version in one step; the switch is itself logged.
Data
Where your data goes, and where it doesn’t.
The default is the strict one. Your data works for you and no one else.
- Training boundary
- Your data never trains other customers’ workers, and is never used to train shared foundation models.
- PII masking
- Personal identifiers are masked before any data leaves your tenant for model inference.
- Isolation
- Each customer’s workers, rules, and logs run in an isolated tenant. No cross-tenant reads.
- Retention
- Logs and Worker Files are retained for the life of the engagement and deleted on request. [Confirm exact window before publish.]
Models
What runs the work, and how it’s constrained.
We disclose our model approach in aggregate and record every route, so results stay reproducible and enterprise constraints are enforceable.
- Providers
- Work runs on established enterprise LLM providers under contract, disclosed in aggregate rather than exposing per-task routing. [Confirm provider list before publish.]
- Routing
- Each duty is routed to the model best suited to it; every route is recorded so results stay reproducible and auditable.
- Enterprise constraints
- Provider allow-lists and data-residency requirements can be enforced per tenant.
- No silent swaps
- A model change that affects how a duty is performed is versioned like a rule change, not shipped invisibly.
Roadmap
Compliance status, dated honestly.
No badges we haven’t earned. Here is exactly where we are.
- Live
Encryption in transit and at rest
All tenant data and logs.
- Live
Tenant isolation & append-only audit log
Per-customer data boundaries.
- In progress
SOC 2 Type II
Audit underway. [Confirm auditor + target date before publish.]
- Planned
Penetration test report on request
Available under NDA. [Confirm availability.]
Want the full security packet, or to see the log against your own workflow? Start with the assessment.
Get started