Two boundaries, and one record#
Policies states the workspace ceiling as commitments in force, with a revision stamp and a region, not as prose. It is organised around the only two questions policy in this product answers: what reaches an audience, and what leaves a device.
Three tabs: IN FORCE is what is true right now, POLICY DOCUMENT is the full text, and HISTORY is every prior revision. Reading needs policy.read; changing anything needs policy.manage.
Reaches an audience#
- Publication
- Verified only. Nothing reaches an audience until a steward has verified it.
- Steward review
- Required. Nothing unreviewed is trusted.
- Source permissions
- Enforce. Admit whatever the source’s own permissions allow, and no more.
- Retention
- How long content is kept. 365 days by default.
Leaves a device#
- Raw upload
- Never. Claims and redacted quotes only. Enabling raw upload is an administrator’s decision on a deployment profile, and it is the single widest change available in this product.
- Default sync
- Summary only. A redacted summary syncs; extraction stays on-device.
- May open
- The file types the agent is allowed to open. Ten by default. Anything not named is never opened.
- Never opens
- Blocked patterns and excluded locations. Nine patterns by default: environment files, private keys, certificate bundles.
- Refused labels
- credential, password, private key, secret, token, refused on the device and again at the plane. Two independent refusals, not one.
- Held for an admin
- Sensitivity labels that route to admin review rather than syncing on a person’s decision alone. confidential and restricted by default.
- Device review · Gate 1
- Whether a person at the device sees a pack before it leaves. Required everywhere by default. It is named Gate 1 because the verification queue is Gate 2, and turning this one off does not touch the other.
Changing a commitment#
Press CHANGE on the commitment
Every row has one. Each opens the control for that one value.
Read the consequence, which is stated first
The console names what starts or stops happening in operator terms, not in enum values. It is written to be accurate rather than reassuring. Turning device review off says the person whose machine it is no longer decides what leaves it, and also says the verification queue still stands.
Write a reason if you are widening
A change that widens, whether that is raising autonomy, allowing raw upload or removing a gate, costs a written reason. A change that narrows applies on one click and never asks, because restricting what a fleet may do is not a decision anybody needs protecting from.
Check what it applies to
Most changes apply at the next reconcile. The control plane address applies to the next enrolment only. Endpoints already enrolled do not move.
Where the ceiling is narrowed
Beneath the commitments, NARROWED BY lists every deployment profile as a delta only: what that fleet restricts beyond the workspace ceiling. A profile showing “no delta” means the ceilings apply to it as written. No profile can ever widen past the workspace.
The audit trail#
Activity is an append-only history of every governed decision and action, admin actions and device events alike, with the full record behind each row. It needs audit.read, which the auditor role holds alongside every read in the product and no write at all.
| Column | What it gives you |
|---|---|
| Actor | Who did it: a person, a device, or the system. |
| Entity | What it was done to. |
| Event ID | The stable identifier to quote in a ticket or an audit finding. |
| Recorded | When the plane recorded it. |
- Every policy change made on the Policies page lands here, with the reason that was given for it.
- Every terminal fleet act (a revoke, a wipe request, a token revocation) lands here.
- Every publication lands here, which is what makes “who certified this, and why?” a question with an answer.
Old links still work
This surface used to be /console/audit-log. That path still resolves, and it redirects here. It was renamed because it records device events too, not only admin actions.
Workflows#
Workflows holds automations, their versions and their bindings, including the human tasks they raise. Reading needs workflow.read; creating, binding and resuming need workflow.manage.
Create a workflow and author its steps
New workflow. A workflow is versioned; a version is what actually runs.
Bind it to a trigger
A binding is what makes a workflow fire. An unbound workflow is a definition, and it will never run.
Watch the runs
The detail page shows the graph, the versions, the bindings and the run history.
Answer the human gates
A run that reaches a human-review step stops dead there, and nothing after the gate has executed. Those tasks appear in the Automation lane of Review, and the run resumes only when somebody decides.
Something here wrong, missing, or no longer true of the product? Write to hello@evodira.com. Documentation that has drifted from the console is a bug and we treat it as one.