Secure, controlled, and operated around the clock.

What comes with every workload

Every workflow JotVision runs comes with the operating envelope around it. There is no platform to buy and staff; these are part of the service.

• Full DevOpsDeployment, upgrades, monitoring, on-call, and incident handling, run by our operators around the clock.
• Human in the loopReview and approval gates per workflow, set by you, from full review to exceptions only. Critic models hold anything outside validation thresholds.
• Access controlProject-level roles for our engineers, our operators, and your team, federated to your identity provider. Every grant is visible and revocable.
• RetentionConfigured per workflow for inputs, outputs, and snapshots, in storage you govern.
• AuditingEvery run, decision, credential use, and administrative action is logged with who, what, and when.
• Release controlsDevelopment and published versions, regression tests against your historical data, and your acceptance before promotion.
• Your infrastructure, ours, or hybridA dedicated, single-tenant instance on cloud we manage, on your cloud or premises, or hybrid. Same posture in every case; the difference is who holds the keys.

How work runs

AI at build time, determinism at run time. AI agents write and adapt the workflow code under the supervision of our forward-deployed engineers, who review every change before it is published. The agent never deploys and never writes to your systems. What runs in production is a published, versioned set of steps, each executing in its own WebAssembly sandbox with access only to the connections it was explicitly given.

Non-deterministic work is gated. Where a model reads an unstructured file or a result needs judgment, the output goes to a review gate: your team, our operators, or an automated critic that scores it against validation rules and holds anything below threshold. As patterns stabilize, we replace model extraction with deterministic parsers.

Decision rights are written down per workflow. You start at full review and move toward exceptions only, at your own pace.

Every run is reproducible. Each execution is tied to a project version (code, prompts, tools, model versions, memory) and a snapshot of its inputs. Any output can be traced to the exact run that produced it, and that run can be re-created.

Hosting and data flows

The JotVision platform runs as a dedicated instance per customer, with no shared tenancy. It is deployed on Kubernetes or Docker Compose: on infrastructure we manage (Google Cloud by default, in the region you choose, with Azure or AWS available when required), on your own cloud or on-premises environment, or hybrid.

In the hybrid model the instance is cloud-hosted and a small on-site component runs inside your network. It executes workflow steps locally in the same sandboxed runtime a browser uses, and connects to the cloud instance the way a browser does: an outbound, authenticated HTTPS connection, with no inbound ports, no VPN, and nothing to open on your firewall. It integrates local systems, file shares, and devices such as cameras. Data that must stay on site is processed on site; only the results the workflow is specified to send cross the boundary.

Data at rest stays in systems you already govern: your document management system, your cloud storage with your encryption keys, or your databases. The platform holds working data for the duration of a run, plus the snapshots needed for reproducibility; where those snapshots live is configured per workflow.

Each workflow has a data-flow diagram in its specification: what comes in and from where, and what is written back and to where. We walk through it with your IT team before anything is connected.

SOC 2 Type II is in progress for workflows we host and operate. For customer-hosted deployments, your own controls apply and we align to them.

Identity, permissions, and credentials

Access is role-based at the project level: Operator, Contributor, and Admin, plus the project owner, with a separate permission set for platform administration. Our forward-deployed engineers hold Contributor access to develop and test. Operators monitor and approve runs and cannot change workflow logic. Your team’s access is scoped to the results and approvals you choose to expose. Every grant is visible and revocable by you.

Identity is handled by an OIDC/OAuth2 identity layer (Zitadel) that federates to your identity provider for single sign-on and MFA. API, CLI, and AI-assistant (MCP) access use OAuth2 tokens with limited scope and expiry, bound to the user who issued them.

Every integration (Slack, Teams, Box, cloud storage, databases, your ERP’s API, any HTTP service) is a platform connection: a typed, named object that a workflow step references by name. Connections are configured by a project admin and must be enabled by a site admin before any workflow can use them, so two people are involved in every new path into or out of your systems. A step can only use the connections its project has been granted; there is no ambient network access.

Credentials are stored once, encrypted, and referenced everywhere else by an opaque ID. If you have a secret manager, we use it, and credentials stay in your control. If you do not, we provide one: Google Secret Manager by default, or HashiCorp Vault where that fits your environment. Workflow code never sees a raw secret; it is injected at run time, scoped to the project and the run, rotated on a schedule, and never written to logs or outputs.

At a cadence agreed with your IT team, we review every human and service grant with you and remove what is no longer needed.

Model providers and data handling

Model calls are made through typed connections with prompt logging. The provider, model, and version used in any run are recorded with that run. You can restrict a workflow to specific providers, to a provider running in your own cloud, or to self-hosted models.

The providers a workflow may use, and each provider’s data-retention and no-training terms, are agreed with you before deployment and recorded in the workflow specification. Nothing leaves your environment to a provider that is not named there.

Model versions are pinned. A provider deprecating or changing a model is a change we manage through the release process, not something that happens to a running workflow.

Retention and deletion

Retention is configured per project and per workflow. For each one, you set how long inputs, intermediate data, outputs, and execution snapshots are kept, and where. The schedule is agreed in discovery and recorded in the workflow specification.

Data stored in your document management system or cloud storage follows your own retention and disposition policies; the platform holds temporary access credentials, not the data.

On request or at contract end, working data and snapshots held on our infrastructure are deleted and the deletion is confirmed in writing. Backups roll off on the window set for that project. Long-term workflow memory, the domain knowledge a workflow accumulates, is stored in your controlled storage and is yours to keep or delete.

Testing and release controls

Workflows have a development version and published versions. Operators and production runs only ever see published versions. A single correction does not change production behavior on its own: changes are made in development, tested against regression sets built from your past runs, reviewed, and published as a new version with a change note written in your terms. At our reference customer, the rebate reconciliation workflow was accepted on a 273-of-273 match against the manual output.

New versions pass a customer acceptance step before promotion. Who may approve a release is set per workflow: us, you, or both.

Our own platform is released through a CI/CD pipeline with automated tests. Continuous security scanning in that pipeline is scheduled for December 2026, and penetration testing is in progress.

Logs and operational monitoring

Every run records the project version, the step code and model versions used, inputs and outputs (or references to them), every review decision and who made it, and every notification sent. Every authentication, admin action, credential access, and AI-assistant tool call is written to an audit log.

Log retention follows the same per-project schedule as the rest of your data. Audit and run logs are available to your team on request, or directly through the JotVision CLI and API, so you can pull them into your own log and compliance tooling.

Monitoring runs around the clock. Jobs that fail or stall retry, pause automatically, and alert our operators. Critics flag outputs outside validation thresholds. Alerts reach your team on the channels you choose: email, Slack, Teams, or webhook.

Incident response and recovery

Some actions cannot simply be undone, such as a price written to the ERP or a claim filed with a supplier. That is why writes pass through the approval tier you set, and why every write carries its run ID.

Incidents are classified by impact on your systems and data, using a severity scheme and notification window agreed with your team before launch. You are notified of any incident affecting your data or a workflow’s correctness, with what happened, what was affected, and what we did.

Rollback is to the previous published version, plus a correction run with the same evidence trail where a write occurred. Every incident gets a written post-incident review shared with you. Incident response never consumes your improvement budget.

Support coverage and continuity

Each engagement has named operators, a customer success contact, and an escalation path, agreed before launch. Monitoring is 24×7. Support is follow-the-sun over email, so a request is picked up by whichever operator is on shift. Urgent operational issues reach the on-call operator through the alerting path above. Response commitments are stated in the service agreement.

Workflows are documented, versioned, and exportable. If a named operator is unavailable, another can pick up from the run history. Continuity of the service does not depend on one person.

Dependencies, export, and transition

The platform depends on a Kubernetes or Docker runtime, PostgreSQL, an identity provider (ours or yours), a secrets store (ours or yours), the model providers named in each workflow, and, in hybrid deployments, the on-site component. There are no hidden third-party services.

Your data, outputs, and workflow memory live in storage you control and can be exported at any time in standard formats (CSV, Parquet, JSON, Markdown). Workflow definitions (code, prompts, validation rules) can be exported as a project archive. At transition we hand over the archive, the run history, and documentation. We will discuss transition options in the agreement.