How to start
- Contact us. Request evaluation packages (v0.1.0). They are not on npm or PyPI. Binaries and SDKs are not public downloads.
- Receive the package. We send binaries,
aaesctl, SDKs, and release-verification public keys with setup notes. 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 contract
The HTTP contract and SDK methods are background reading. They are not step 1 of evaluating.
Bring a bounded evaluation environment
- A dedicated test host with synthetic data, a workflow owner, and an authorized approver.
- The evaluation install, with operator identity and a caller token from the package we send.
- 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 verb, 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.
From setup to a governed result
- Establish identity and custody. Test operator login and role mapping. Connect credential references through your vault; keep root keys and vendor credentials out of the browser.
- Define the work. Register the agent, manager, capability, and resource. Give the work 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 through the SDK or MCP.
- Approve and run. Have an authorized person approve the exact request you will run. Keep the same work and effect identifiers when executing it. 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 the 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. |
Client-operated evaluation is the current delivery scope. Managed hosting is not offered today. Custom domains, branded login, and embedding are not implemented. Independent security assurance has not been completed, and no product availability SLA is offered. Any future offering would require implementation, validation, and separate written terms; no delivery date is promised.