Plan the evaluation before you book it.
For the engineers and security reviewers running an OCNORA evaluation: a pilot scope to fill in, what to prepare, the security and architecture review, the success criteria you set, and the order the steps run in. Print it, fill it in, bring it to the demo.
One page that says what the pilot is, and what it is not.
Fill in each row before the architecture review. It becomes the core of the written pilot plan.
| Field | What to write | Your answer |
|---|---|---|
| Business owner | The person who decides whether the pilot succeeded, and signs off. | |
| Technical owner | The engineer who runs the installation or the workspace and joins the architecture review. | |
| Workflows in scope | The workflows the pilot will run, each with its trigger and the result it must produce. Real work, kept small. | |
| Out of scope | What the pilot will not cover, written down so the pilot is not measured against it. | |
| Deployment option | OCNORA Cloud, your cloud with Docker Compose or Helm, or embedded in your product. | |
| Sign-in | Email and password with MFA, or OIDC single sign-on through your identity provider. | |
| Key backend | Local master key, Google Cloud KMS or AWS KMS. | |
| Systems connected | Each system the workflows read from or write to, and whether a test or production account is used. | |
| Data classes | What kind of data passes through: personal data, credentials, financial records, none of these. | |
| AI use | Whether a workflow calls a model, which vendor or local model, and the budget it runs under. | |
| Success criteria | The measures from the success criteria section below, with the target you set for each. | |
| Dates | Start, review and decision dates you agree with us. |
Claim procurementPath · unverified · checked 2026-09-28; Claim deploymentOptions · unverified · checked 2026-09-28; Claim dashboardSso · implemented · checked 2026-10-20; Claim encryptionBackends · unverified · checked 2026-09-27.
Systems, workflow and data, before the first call.
The more of this exists before the demo, the more of the demo is spent on your workload rather than on questions.
Systems
- The list of systems the workflows touch, with an owner for each.
- Test accounts or sandboxes where the vendor offers them, and the credentials to create connections with.
- For your cloud: a host for Docker Compose or a Kubernetes cluster for Helm, plus Redis and MongoDB you can run and back up.
- Your identity provider details if you want OIDC single sign-on, and your key backend if it is a cloud KMS.
Workflow
- A written description of each workflow as it runs today: trigger, steps, decisions, who is involved.
- Where a person has to approve or answer before the work continues.
- What should happen when a step fails: retry, a fallback path, or a person told.
- If you run n8n today, the workflow exported as JSON, so it can be imported and checked.
Data
- Sample inputs that look like production, with personal data removed or synthetic.
- The data classes involved and any rule about where that data may be stored or processed.
- Who in your organisation has to approve the data flow before the pilot touches real records.
- How long run records and the audit log need to be kept.
Coming from n8n? The n8n switching guide says what imports and what does not.
What your reviewers check, and the questions to bring.
Each step is answered from what ships today. The detail behind each is on the enterprise and security pages.
- 01
Security questionnaire
Send us your questionnaire. We answer it from the documented controls on the security page and share the design notes behind them under NDA. OCNORA holds no third-party security attestation, and the answers do not stand in for one.
Claim securityReview · unverified · checked 2026-09-27; Claim procurementPath · unverified · checked 2026-09-28.
Questions to bring- How are connection secrets encrypted, and who can decrypt them?
- What does the audit log record, and can it be exported?
- How are personal data and deletion handled?
- Who do we report a vulnerability to?
- 02
Deployment and network
Walk through the deployment option you chose with the engineers: which process roles run, where Redis and MongoDB live, what leaves your network and what does not.
Claim deploymentOptions · unverified · checked 2026-09-28; Claim offlineLicence · unverified · checked 2026-09-27.
Questions to bring- Which process roles do we run, and which can scale on their own?
- Which outbound calls does a workflow make, and to where?
- Does a self-hosted licence call home?
- 03
Identity and access
Confirm how your people sign in and what each role may do. OIDC or SP-initiated SAML 2.0 is confirmed against your identity provider here, and so is SCIM 2.0 provisioning from it: provisioned users arrive as viewers and get their roles in the app.
Claim dashboardSso · implemented · checked 2026-10-20; Claim scimProvisioning · implemented · checked 2026-10-20; Claim rbacPermissions · unverified · checked 2026-09-27.
Questions to bring- Does our identity provider work with this installation over OIDC or SAML 2.0, and which do we use?
- Will our identity provider provision users and groups over SCIM 2.0, and who assigns roles after that?
- Which of owner, admin, editor and viewer does each group get?
- How do embedded users arrive, if we embed it?
- 04
Keys and secrets
Choose the key backend that wraps each connection secret’s data key: a local master key for a pilot, or Google Cloud KMS or AWS KMS. Azure Key Vault and HashiCorp Vault are not offered.
Claim encryptionBackends · unverified · checked 2026-09-27.
Questions to bring- Which backend matches our key policy?
- Who holds the key, and how is it rotated?
- 05
Controls on the pilot workflows
Check the controls your pilot depends on against the workflows in scope: human approvals, Workflow Health checks before a run, the run record and audit log, and AI budgets.
Claim humanApprovals · unverified · checked 2026-09-28; Claim workflowHealth · unverified · checked 2026-09-28; Claim runAudit · unverified · checked 2026-09-28; Claim aiBudgetUsage · unverified · checked 2026-09-28.
Questions to bring- Which step needs a human approval, and what happens on timeout?
- What does Workflow Health flag before the first run?
- Where is AI spend capped, and what happens when the budget is reached?
You set the targets. We agree to them in the plan.
Pick the measures that matter for your workflows and write the target for each. We do not suggest a number, and no pilot outcome is promised in advance.
| Measure | How it is checked | Your target |
|---|---|---|
| The workflows run | Each workflow in scope runs from its trigger to its result on your systems, in the deployment you chose. | |
| Failures are handled | A failing step retries, takes its fallback path or reaches a person, as you specified in the preparation. | |
| Approvals hold | A run that needs a person waits for that person, and the decision stays with the run. | |
| You can trace a run | For any run, your team can find each step’s input, output and the connection it used. | |
| Access follows your rules | People sign in the way you require, and each role can do only what you assigned it. | |
| AI spend stays inside the budget | Model calls are on the ledger and stop at the budget you set. | |
| Your team can change it | Someone on your team, not us, edits a workflow and publishes it through the checks. | |
| Security sign-off | Your security reviewer accepts the questionnaire answers and the architecture. |
Claim procurementPath · unverified · checked 2026-09-28.
From first call to quote, in order.
Durations depend on your review process and are agreed with you in the pilot plan; this page does not promise one. Write your dates beside each phase.
- 01
Technical demo
One call on the workload you describe, sketched on the canvas together.
OutcomeWhether OCNORA covers it, and which deployment option fits.
Date - 02
Scope
You fill in the pilot scope template above; we review it with you.
OutcomeAn agreed scope, with what is out of it.
Date - 03
Security questionnaire
We answer your questionnaire from the documented controls, with design notes under NDA.
OutcomeAnswers your security reviewer can assess.
Date - 04
Architecture review
A session with the engineers on deployment, network, identity provider, key backend and process roles.
OutcomeA deployment recommendation for the pilot.
Date - 05
Pilot plan
A written plan: the workflows, the deployment, the success criteria you set and who signs off.
OutcomeA plan both sides have agreed.
Date - 06
Pilot
A workspace or a signed licence file to run the real thing. Docker Compose is usually enough.
OutcomeThe workflows in scope running on your systems.
Date - 07
Review and quote
You measure the pilot against your criteria; we quote for the deployment you would run.
OutcomeYour decision, and a quote per deployment.
Date
How a quote is shaped is on the pricing page.
Claim procurementPath · unverified · checked 2026-09-28; Claim offlineLicence · unverified · checked 2026-09-27.
Bring your scope to a technical demo.
Send the workflows and the deployment you have in mind. We come back with the next evaluation step and walk the architecture with you on the call.