Trust · Governance
Understand the governance principles behind identity, permissions, approvals, versions and recovery, then explore how they affect business results in synthetic scenarios.
Governance principleThe server decides identity from the real person or service, the delegation, the tenant and the current policy. An agent works on behalf of a person or service identity, and the delegation can be revoked. A role claimed in a request changes nothing.
In practiceAuthorize actual users or service identities. Role switching in the demo illustrates visibility only.
Governance principleReading, drafting, publishing and changing permissions are authorized separately. Reading doesn’t imply writing; proposing a change doesn’t imply approving it. A database account that can read everything doesn’t mean every end user can.
In practiceWhen connecting your instance, read its current tool catalog and authorize the required tools and resources.
Governance principleChanges that affect users need approval. An approval binds the plan, base version, principal, resource, scope and expiry; if the plan changes or access is revoked, it must be reviewed again. An agent can’t approve itself through another tool. Access is checked again at commit.
In practiceThe interactive demo simulates approvals and state changes. Actual commits follow the approval process in your instance.
Can also end asRejectedExpiredConflictFailedCancelled
A cancel or dropped connection doesn’t mean nothing was written. Query the final state instead of retrying blindly; the same idempotency key returns the original result.
Governance principleKnowledge is versioned. A rule’s business-effective time and its approval time are recorded separately. Past questions are answered either as known then or recomputed with today’s approved rules, and past conclusions are never silently rewritten.
In practiceUse S3’s synthetic policy to compare business-effective time with approval time.
Governance principleIt depends on where the agent and model run. The three paths below need to be read separately. Deploying DataFocus locally does not by itself keep data on premises.
In practiceThe interactive demo uses synthetic data in your browser without connecting to an enterprise instance or model.
With a local model too, data can stay inside. If any step uses a cloud model, check which results leave.
Results returned to a cloud agent leave the company boundary, so scope, redaction and egress need prior approval. A cloud client may not reach your internal addresses at all.
Example data and actions stay in the browser, without an enterprise-instance or model connection. Demo roles illustrate the workflow; instance permissions govern real data.
Governance principleThe platform records who called what, with which sources and definitions, the returned scope and refusals; writes record before and after, the diff, the approval and the commit. Logs themselves need redaction, access control and retention. The platform does not see an external agent’s full conversation, reasoning or final output, and shouldn’t claim to.
In practicePage activity in S1–S4 shows the actions in the current demo and clears on refresh.
Governance principleRevoking access stops future access but can’t recall data already handed to an external client. Rollback covers only context changes with verified versions and compatibility; side effects in other systems need compensation. With writes switched off, completed states and records stay readable.
In practicePrepare backups and recovery for your deployed version. Import cases into separate projects and preserve existing business data.
Enterprise deployment
Start with one business task, confirm these conditions in your instance, then expand the data and usage scope.
