Legal

Core posture

Ontic is designed to verify consequential AI claims against authoritative sources, not to maximize collection of user data. We minimize what enters the system and keep access scoped to the workflows and actors that require it.

How data is handled

Data handling depends on deployment model, but the same control objective applies across environments: only the minimum data needed to verify a claim should be processed, and that processing should remain attributable and auditable.

• Least-privilege access to governed sources
• Explicit separation between application, model, and source authority
• Traceable evidence lineage for consequential outputs
• Deterministic audit records for review and investigation

Commercial and legal details

Production privacy terms, data processing commitments, and customer-specific handling obligations should be defined in the governing commercial agreement, DPA, or related contract documentation.

Public site use

The public website is informational. It describes Ontic's operating model, architecture, and product direction, but it does not by itself create production commitments, warranties, or service obligations.

Commercial engagement

Production use, deployment obligations, support expectations, data handling terms, and service boundaries should be defined in a written agreement between Ontic and the customer.

Why this matters

Ontic is built for high-stakes environments. Those environments require precise contractual language around responsibility, evidence handling, security scope, and regulatory obligations.

System architecture

Security starts with clear trust boundaries. Ontic separates application surfaces, inference pathways, and source authority so governance decisions are not hidden inside a single opaque runtime.

• Explicit trust demarcation between app, model, and evidence layers
• Deployment patterns that support VPC and isolated execution environments
• Policy-aware control surfaces instead of best-effort post hoc monitoring

Access and authorization

Ontic uses policy and relationship-aware control patterns to ensure access is evaluated at the moment claims are retrieved, transformed, or emitted.

• Least-privilege access evaluation
• Role and relationship boundaries on sensitive data paths
• Operator-visible enforcement outcomes when authority is missing

Evidence and forensics

Security claims are only useful if they can be examined later. Ontic emphasizes deterministic logs, evidence chains, and replayable decision paths so incidents can be reconstructed without guesswork.

Control objective

The primary goal is simple: consequential outputs should only pass when the required authority is present. Where evidence is missing, the system should block, label, or escalate rather than improvise.

Audit readiness

Ontic is designed to produce artifacts that internal teams, customers, insurers, and regulators can actually inspect.

• Traceable claim lineage to source authority
• Deterministic records of what was authorized or blocked
• Consistent evidence structures across deployment tiers
• Replayable outputs for investigations and control testing

Deployment reality

Compliance is not a single framework or badge. Ontic provides enforcement and evidence. Domain-specific legal and regulatory obligations still need to be mapped to the deployment environment and the customer's operating model.