Choose your evaluation
Scope the evaluation as Operate, Govern, or both before installing. Each path has different acceptance evidence:
- Operate. Evaluate corporate sign-in, private projects and tasks, configured model-provider or agent-runtime connections, operational history and recovery.
- Govern. Connect an existing agent to configured policy, approvals and evidence.
- AAES Operate + Govern. Evaluate supported Operate work with reviewed Govern execution bindings. Follow the combined integration boundary and qualify the exact release and workflow before relying on combined execution.
How to start
Choose a setup path for your products and deployment. You can manage the installation yourself; implementation assistance and support are optional.
- Contact us. Request evaluation packages. The evaluation package runs in your environment and comes only with the paid design partnership. The design partnership costs USD 40,000 for three months and covers AAES Operate and AAES Govern, starting after signing and onboarding. If you continue, the fee is credited in full against the first-year subscription.
- Receive the package. We supply the selected product evaluation package, release-verification public keys and setup notes. The Govern package holds the Govern binaries, including
aaesctlandaaesmcp. It does not include the SDKs, which you install from PyPI or npm. Use the product-specific CLI, SDKs and MCP setup instructions supplied with your evaluation. Any supplied test credentials or keypairs are identified as synthetic and must not be used for production; deployment signing keys are generated under your control. Remaining setup notes ship with the package. - Install on a test host. Use a dedicated test resource with synthetic data, a workflow owner, and an authorized person who can approve.
- Run the checks below on that install.
Pre-read the product contracts
You can read the Govern documentation, Operate integration status and combined boundary before requesting an evaluation. The Govern Python package is aaes-govern-sdk, the Govern TypeScript package is @aaes-ai/govern-sdk, and the Govern container image (ghcr.io/aaes-ai/aaes) is public. The published Govern SDK releases are aaes-govern-sdk 0.1.3 on PyPI and @aaes-ai/govern-sdk 0.2.0 on npm.
The public Apache-2.0 aaesverify release and synthetic sample are on the verification page. Using that verifier under its license requires no separate evaluation authorization.
Bring a bounded evaluation environment
- A dedicated test host with synthetic data, a workflow owner, and an authorized approver.
- The selected evaluation install and configured operator identity. Govern caller tokens are issued by the deployment operator; Operate uses its own corporate sign-in and private-resource permissions.
- A vault-backed credential and network path for the tested workflow. Show that the credential path is controlled, and name remaining bypasses.
- An agreed budget, allowed action, approval rule, and a way to observe the provider's actual outcome.
Use a synthetic or local vendor-format workflow, such as a local Jira-shaped server. A live vendor tenant is a design partnership.
Govern: from setup to a governed result
- Establish identity and custody. Test operator login and role mapping. Connect tool-credential references through your vault and keep deployment root keys out of the browser.
- Connect your agent. Register an existing agent in AAES Govern and complete its generated setup handoff. Assign an accountable human manager. Registration alone grants no tool permissions.
- Define the task and access. Register the required capabilities and resources, and grant the agent the permissions it needs. Give the task an explicit budget and deadline.
- Review and activate the rule. Require the intended approval, validate the configuration, and check its activation status.
- Show the credential path. For the tested workflow, show that the credential path is controlled, name remaining bypasses, then request the action from the connected agent through the Govern SDK, API, or MCP.
- Approve and run. Have an authorized person approve the exact request you will run. Resume only after the required approval is recorded. Connected integrations must preserve the same task and effect identifiers when executing the approved request. If the provider's result is unclear, check what happened before retrying.
- Check the receipt and the system. Confirm the external change, inspect the sealed receipt, then verify an export from this evaluation install using the separately held public key. There is no public sample of a client evaluation export; a synthetic demonstration export is published on the verification page. Exercise a rejection and recovery before expanding scope.
Make Govern acceptance criteria explicit
| Question | Required evidence |
|---|---|
| Is the credential path controlled? | Credential custody and network checks on the tested workflow, with remaining bypasses named. |
| Do approvals and budgets hold? | Allowed and rejected actions, expired approval, duplicate effect, and over-budget cases. |
| What happened externally? | Provider outcome and receipt agree; uncertain outcomes remain visible. |
| Can operations recover? | Restore and rollback using independently retained trust, then readiness and verification of an export from this install. |
| Who supports the deployment? | Named operational owners, agreed support scope, and a handover. |
AAES Operate and AAES Govern can be client-operated or hosted by AAES. Agree the deployment, operating responsibilities and support scope before evaluation. Custom domains, branded login, and embedding are not implemented. Independent security assurance has not been completed, and no product availability SLA is offered. Capabilities described as planned require implementation and validation; no delivery date is promised.
Evaluating AAES Operate
The Govern workflow and acceptance table above do not evaluate AAES Operate. An evaluation of AAES Operate, the operating layer, is scoped separately in the design partnership: deployment in your environment, configured model-provider or agent-runtime connections, private task assignment, initially paused schedules that an owner or administrator enables, failure recovery, cost reporting boundaries and agreed support scope. See the Operate acceptance outputs. Operate operational reviews, permissions and spending limits are not Govern policy or evidence. Its standalone evaluation uses its own acceptance criteria.
Evaluating AAES Operate + Govern
First satisfy each product's standalone identity, private-access and recovery criteria. Then review the exact Operate task, agent (Claude, Codex or HTTP) and Govern execution binding with the authorized owner of each product. Configure the Govern policy, capabilities, task and approval path for that workflow; qualification must cover the exact supported release.
Exercise an allowed request, permission removal, policy refusal, approval expiry, unknown provider outcome and an unavailable Govern service. Combined execution must stop when Govern cannot authorize it. Preserve original project, task and agent identifiers and operational history; do not describe earlier history as governed evidence. Review the combined integration guide before expanding scope.