Built for the auditor, not the marketing slide
The trust page exists to answer the questions a CISO, Chief Compliance Officer, General Counsel, or external auditor asks before a procurement decision — with concrete framework coverage, the open verifier, our sub-processor posture, and the regulatory calendar that governs our roadmap.
Encryption-first architecture
Gateway requests produce Ed25519-signed receipts; receipt claims are negative-tested against tampering. An auditor can verify a session export end to end, offline, using only a public key — no access to VeilEngine systems required.
Auditor-verifiable evidence
Cryptographic receipts link into a per-session, tamper-evident chain. Auditors run the open verifier CLI against an exported session evidence package, all offline. The evidence holds without trusting our platform.
Framework requirements as constraints
Customer, auditor, and counsel requirements are documented for the selected workflow. Public framework mappings are not claimed; any future mapping requires its named evidence gate.
Requirements the buyer may bring — scoped to one workflow
These references identify requirement families that may affect a workflow. The buyer’s counsel, compliance team, and auditor define the applicable obligations. Vertical Edge AI does not claim public control mappings, conformance, certification, or a legal conclusion.
HIPAA / HITECH
Healthcare workflows require the organization’s existing HIPAA program, an executed provider relationship where required, and workflow-specific data handling, retention, and decision controls. Vertical Edge AI does not replace those obligations or represent framework compliance.
SEC Reg S-P · SEC Rule 17a-4
The firm defines its safeguarding, retention, and retrieval requirements. Eligible Tier 1 gateway requests produce signed receipts and a per-session hash-linked chain; mapping those artifacts to Reg S-P or Rule 17a-4 remains roadmap and is not a compliance conclusion.
NAIC AI Model Bulletin
The buyer defines applicable NAIC and state DOI requirements for the selected workflow. Configured retention and per-session signed evidence are engagement-scoped; no public control mapping or cross-session replay claim is made.
ABA Model Rules
Counsel defines the applicable confidentiality, supervision, privilege, and work-product requirements. Tier 1 gateway eligibility is assessed per workflow. Tier 0 client-side protection remains roadmap and is not currently offered.
FERPA · COPPA · IDEA
The institution defines applicable education-record, consent, disclosure, retention, and accommodation requirements. Any consent-vector or identifier-handling control is configured and tested for the selected workflow; this page does not establish FERPA, COPPA, or IDEA compliance.
GDPR · CCPA / CPRA
The customer defines applicable lawful-basis, erasure, security, DPIA, opt-out, and disclosure requirements. These may become workflow constraints; no GDPR, CCPA, or CPRA mapping or compliance conclusion is claimed.
NIST AI RMF
NIST AI RMF requirements may be scoped as workflow constraints. This page does not establish conformance, complete mapping, or universal control evidence.
EU AI Act
EU AI Act risk, data-governance, recordkeeping, transparency, and human-oversight requirements may be documented as workflow constraints. No conformance or complete mapping is claimed.
State + sectoral AI laws
Applicable state and sectoral requirements are identified by the customer and counsel, then documented as workflow constraints. No public jurisdictional mapping or legal conclusion is claimed.
Auditors verify offline — no platform trust required
The verifier CLI is the load-bearing artifact of the trust architecture. Your auditor downloads it, points it at an exported session evidence package, and confirms each receipt’s cryptographic signature and the package manifest — without any call to our infrastructure, without any dependency on our continued operation. The package carries a per-session hash-linked chain; automated chain-walk verification in the CLI is on the roadmap.
If Vertical Edge AI ceased to exist tomorrow, the evidence you hold today would still verify. That is the design constraint, and it’s the reason the verifier is MIT-licensed — audit it, modify it, redistribute it — rather than a closed service. The license ships in the sample package.
- Offline operation — no network calls, deterministic outputs, reproducible across auditor environments
- Cryptographic chaining — per-receipt signatures, a per-session hash-linked chain, tamper-evidence (cross-session transparency-log inclusion evidence: roadmap)
- Round-trip integrity (roadmap) — a future utility and boundary-check artifact; per-request evidence bundles are not yet emitted.
Structural safety, not behavioral
The design threat model treats agents as untrusted within workflow-specific boundaries. Eligibility and enforcement must be established for the selected workflow; this is not a universal coverage claim.
Encryption-first execution
Tier 1 gateway eligibility, its protection policy, and its provider boundary are established for the selected workflow. Tier 0 and Tier 2 remain roadmap.
Verifiable evidence fabric
Append-only, hash-linked receipts and an open verifier mean auditors trust the evidence, not the platform.
Output verification gates
Output-validation, threshold, and human-review requirements are defined for the selected workflow.
Provider abstraction
Provider requirements and portability are evaluated per workflow. No universal portability or compliance-posture claim is made.
Immutable audit trail
Gateway requests produce Ed25519-signed receipts, and an auditor can verify a session export offline using only a public key. Broader action-level lineage remains engagement-specific or roadmap.
Instant suspension
Stop authority, suspension procedures, logging, and review requirements are defined for the selected workflow before operation.
Sub-processor relationships are scoped to the selected workflow
Tier 1 is the live gateway path, with eligibility and the protection policy scoped to the selected workflow. Tier 0 client-side protection and Tier 2 provider-under-agreement routing remain roadmap designs and are not currently offered as engagement paths.
Provider, evidence-store, and runtime-host requirements are established during workflow scoping. Any register, purpose limitation, notice term, opt-out, or data-processing agreement must be confirmed in the signed engagement; this page does not represent those terms as universally available.
Provider eligibility is not the same as an executed agreement. The required provider relationship, data handling, retention, and workflow controls are engagement-specific and must be confirmed before implementation.
The full register, with the data category each party may touch and the residency of each, is shared under engagement — not published here, by design.
This marketing site itself sets no tracking cookies; visitor traffic is measured with cookieless, aggregated analytics only.
The deadlines that move our roadmap
This research calendar tracks source changes that may affect customer-defined workflow requirements. It does not claim a public control mapping, customer notification service, or compliance conclusion.
Run the verifier yourself — the sample package is public
The sample evidence package and verifier are a public download — no form, no NDA, no sales call. The synthetic package establishes only that its sample signatures and hashes can be checked offline; it does not establish production deployment, engagement availability, or a customer signing arrangement.