Inspect the controls before you sign.
Evidence your security architects can test. Before a worker handles live traffic, your team can read its definition, run it in mock mode on synthetic data and verify the export's signed inventory offline. An optional red-team module adds known attack techniques. Below: what holds today, what is opt-in, and what we do not claim.
EU personal-data practice
California consumer-privacy practice
Platform data, transit and rest
Approval gates in workflows
Security and availability attestation
Top priority — target date: being finalized.
ISMS certification
AI management standard
Accessibility report (VPAT)
“In place” means the control runs today. “Roadmap” means certification work under way, not a certificate held; nothing is shown as certified before an audit report is issued. Email security@nxgyle.com for current status and evidence.
Several tiles carry a Roadmap label deliberately. Each tile reports current state rather than intent, and every page applies the same rule.
SOC 2 Type II — target date: being finalized.
Until then, your security team has three options.
- Run workers inside your own environment, under the controls already enforced there.
- Request the audit-trail specification before deployment.
- Inspect redacted files from a sample export, on request.
Threat-modeled and build-checked.
Every export carries its own threat model, organized by component, and must pass a build check before download. The list that follows applies to the Studio platform we operate.
- Platform data encrypted at rest and on the wire
- Role-based access to the Studio at tenant and workspace level
- Access to each exported worker sits behind your own network controls
- Prompt-injection and toxicity guards for workers are opt-in; Studio uploads get an advisory injection screen
- A coordinated-disclosure route for reported vulnerabilities
Test without production data.
Test runs use per-worker synthetic datasets, and mock mode answers tool, connector and sub-worker calls from canned response packs, keeping live systems out of the test; AI steps still call your model provider. After export, the worker runs in your environment and no Nxgyle service sits in its data path.
- Synthetic datasets, AI-generated per worker or imported from spreadsheet or data files up to 200,000 rows
- Mock mode stands in for every external system, with normal, empty, error and timeout responses
- Studio data stays inside Nxgyle operations (Herndon, Virginia; Hyderabad, India)
- GDPR and CCPA practice for personal data, with deletion on request
- Named sub-processors, listed on request
Each decision traced to its origin.
Governance ships as code, not as a policy appendix. Each automated decision in a worker traces back to a rule check, an approval gate or the run log.
- A versioned workflow definition instead of logic hidden in prompts
- Fixed rule checks make no model call: the same input always yields the same verdict
- Paused runs survive restarts; each resume runs exactly once and refuses a changed workflow
- An optional tamper-evident audit log with signed seals your team verifies offline
- An optional masking module for personal and health data; without it, exports run unredacted and say so
Four mechanisms you can test yourself.
Each can be examined three ways: a live session with our engineers, documents for your auditors, or the run log of a past test run. Deterministic replay is opt-in. Pick the route your review process needs.
Rehearsal before reality
Each worker gets its own synthetic dataset, AI-generated or imported. Mock mode answers tool, connector and sub-worker calls from four response sets (normal, empty, error and timeout) without touching live systems, and it ships in the export. Paused test runs wait in the Studio for an approver. The simulation lab runs several workers on an accelerated clock, and an optional red-team module produces a scorecard without blocking export. Since no production data is touched, a written process outline is enough for security to sign off on an evaluation.
Testing in Nx·StudioRules you can rely on
Nx·Studio's AI analyst turns stated policy into fixed rule checks where it can. Each one passes, halts, warns or branches without a model call, so its verdict is reproducible. A rule-direction lint catches inverted conditions, and policies it could not encode are flagged. Unwritten decision logic is handled by the Cognitive Engine. That product sits outside the workers, takes requests via the Cognitive Studio, and acts only after a zero-error exam on held-out cases.
Cognitive Engine architectureBlueprints you can read
A worker is defined in a versioned workflow definition, not scattered prompts: tasks, connections, approval gates, routing and decision rules. Versions support fork, branch, tag, diff and three-way merge. Swimlanes give business owners a readable view, engineers get the exported definition, and the Studio generates an exact summary of what was built. The definition ships with the code and belongs to you.
Governance documentsProof in every export
Every export includes its AI bill of materials, listing models and providers, agents with fingerprints of their prompts, connectors, tool code and dependencies. A signature covers a fingerprint of every exported file, and the bundled verifier checks it offline. The package also includes its component-level threat model, plus a template for Article 53 of the EU AI Act. Nothing at run time depends on Nxgyle: no runtime of ours, no license check, no meter, no phone-home.
Inspect a sample exportCheck every export without calling us.
Each export package includes its own proof of contents: a signed statement that fingerprints every file and the AI bill of materials. Your engineers run the bundled verifier offline, on equipment you control. An itemized ownership report comes from the Studio. You can request a redacted sample; the verdict is yours.
At run time the code contacts only endpoints you configure; nothing of ours runs beside it, and it has no license check, usage meter or callback. Your engineers can confirm it by reading the code and watching its traffic.
Rule behavior is shown the same way. In a live session, give us one case, run it twice, and compare the two outcomes your rule steps produce.
- Signed AI bill of materials A signed inventory of models, agents, tools and dependencies, with an offline verifierin the ZIP
- Component threat model Threats per component against a data-flow diagram, with controls marked to verifyin the ZIP
- Article 53 template Article 53 documentation filled from the AI bill of materials; not a conformity assessmentin the ZIP
- Ownership report A manifest of every delivered file, plus a stakeholder PDFStudio-generated
Run each check on your own machines; the verdict stays with you.
The worker’s logic is reviewable before deployment.
Oversight should not mean a dashboard over a black box. Here it is a definition you can read, diff between versions, merge and archive.
One definition, three reviewers
A versioned definition describes each worker: agents and roles, connections, approval gates, routing and rule steps. Nothing lives in hidden prompts or a vendor’s runtime. Engineering can diff, branch and merge it like source code, governance approves it before launch, and auditors test the running worker against it later.
Approval history and field lineage
Every approval lands in an audit trail naming the approver and time. The tamper-evident log (chained and signed) and field-level lineage are optional and off by default. Rule steps return one verdict for one set of inputs.
The reviewer inbox is your code
An approval gate pauses the worker until someone answers. Exports with gates also ship a reviewer inbox application that your engineers wire to the worker. Maker-checker is enforced: a requester cannot approve their own item. Slack delivery is optional, email goes through one supported service, and reviewers are mapped to roles or teams in software you own.
Test data and design inputs, kept apart.
Each worker’s own process can get a generated synthetic dataset, which lets previews, simulation runs and red-team exercises proceed without production data. Imported samples stay inside your workspace, where only its members can see them.
Material you supply while a worker is designed travels a separate path. Uploaded documents and process logs shape the design to your real volumes. What gets shared is your choice, it serves only the design of your workers, and we settle data-processing terms with you before any transfer.
An evaluation can begin with only a written description of how the process runs.
Which steps are deterministic, which are probabilistic, and who decides.
Model calls can return different answers.
So stated policy never depends on them. Wherever possible it runs as rule steps in the worker, so each input maps to one answer. Every run writes a run log to confirm it, and deterministic record and replay is opt-in. Decisions never written down as rules belong to our Cognitive Engine, a separate product reached through its own Studio rather than a component of Nx·Studio workers. Its training data is limited to verified outcomes, and it decides only after passing an exam on held-out cases.
Where a step needs model judgment, a quality check can score the output. You set the threshold and the response to a low score: flag it, end the run, or route the case elsewhere, such as to a reviewer. By default it only flags. Approval gates keep the worker paused until someone decides.
Where people step in is your design choice.
Six artifacts your architects can request.
Each is sanitized before it leaves us. Request them through security@nxgyle.com.
Redacted worker definition
A sample worker's definition, swimlane view and export summary, so architects can review intended behavior before deployment.
Sample test-run trace
Step trace, timings and per-event cost from one synthetic-data test run.
A trimmed sample export
Folder layout, README, tests and container definition from a sample export: the codebase your engineers would inherit.
Redacted threat outline
The threat categories and mitigations each export's model covers, with configuration detail removed.
Audit-trail specification
The events recorded, and how the optional hash-chained log and its signed seals expose later edits.
Sample ownership report
File manifest, signed AI bill of materials and verifier output from a sample export, ready for engineering to check.
Review the definition, the evidence and the code before any live traffic.
Claims you can test yourself.
One sentence apiece, bounded by what the code demonstrates. A narrow claim you can verify beats a broad one you cannot.
Testing a worker requires no production data or live connection.
Exported code holds no Nxgyle endpoint, license check or meter.
Exported workers keep running on your infrastructure after the contract ends.
Figures here come with their method. Whatever lacks an honest measurement stays unpublished.
Third-party statistics follow the same rule and appear only with source and date. Delivery counts are computed from the published catalog data at build time and re-checked before each release. A number we can no longer reproduce comes off every page.
Availability and incidents
Exported workers run in your environment and report health and metrics to your own monitoring, so their uptime follows your SLAs, not ours. Paused runs survive restarts. Our platform is monitored with a defined incident process, and we intend to publish a status page.
Direct contacts
- Security & documentation security@nxgyle.com
- Data-rights requests privacy@nxgyle.com
- Accessibility accessibility@nxgyle.com