This AI Transparency Statement is published in compliance with the U.S. Federal Trade Commission’s AI policy framework (March 2026) and in preparation for EU AI Act transparency obligations effective August 2, 2026. It explains how ORA’s AI operates, what decisions it makes autonomously versus with human approval, its known limitations, and the governance mechanisms that keep it auditable.

1. What ORA Is

ORA is a governed AI operator: AI software that executes multi-step tasks, makes decisions, and interacts with tools and files on your behalf — behind a fail-closed security broker. The broker sits between the AI and your machine and enforces hard floors: destructive actions are blocked by default, risky actions require your explicit approval, and every action is recorded on a tamper-evident audit chain. ORA is local-first and model-agnostic: it routes inference to the models you configure — local models on your own hardware, or cloud endpoints you explicitly enable.

ORA is not a model. It is an operations and governance layer. The underlying language models are supplied by whichever providers you configure. ORA governs how those models are used, what actions they can take, and under what conditions human approval is required.

2. Content Labeling

Under FTC guidance (March 2026), we disclose the following about ORA-generated content:

AI-generated: Content where ORA agents produced the primary output (research summaries, drafted communications, analysis reports, code)
AI-assisted: Content where a human author used ORA for research or structure but substantially revised the output
AI-enhanced: Content with minimal AI involvement (grammar correction, formatting)

When ORA agents produce outputs you intend to share externally (emails, reports, social content), you are responsible for appropriate disclosure as required by applicable law in your jurisdiction.

3. The Operator and Its Tools

ORA runs as a single governed operator working through audited tools — a governed shell, file access, research, drafting, and business operations (leads, jobs, invoicing). Every tool call passes through the security broker.

Capabilities: Task planning, research and analysis over your local files and memory, drafting content and communications for your review, and operating your configured business workflows.
Limitations: Cannot act outside its configured tool list. Cannot exceed your configured authority level without human approval. Like all AI systems, it may produce incorrect analysis — outputs should be reviewed.
Human oversight triggers: Anything destructive, anything that spends money, anything that sends or publishes externally, and anything the broker classifies as high-impact.

4. The Constitution and Authority Levels

ORA’s governance is anchored by a constitution — a rules file the operator always follows. Some rules are locked (for example, bulk data exfiltration is blocked) and ORA will refuse to save a constitution that drops them. On top of the constitution, an authority scale from A0 to A5 sets how much ORA may do without asking:

A0 — advise only: ORA suggests; it executes nothing.
A1 — always ask: every action requires your approval.
A2–A3 — routine autonomy: small, reversible, local actions run alone; everything risky is queued for approval.
A4–A5 — broader autonomy: more runs unattended, but the hard floors (destructive block, external sends, spend, exfiltration) still require your yes.

Every proposed action is evaluated for impact, reversibility, and evidence before it is either executed or routed to your approval queue in plain English.

5. What ORA Agents Can Do Autonomously

By default, ORA agents may execute the following without human approval:

Read files and directories within your configured workspace
Search and retrieve from MCP memory
Query system status and metrics
Draft content for your review
Call configured read-only API tools

6. What Always Requires Human Approval

Regardless of governance configuration, the following actions are never executed without explicit human approval:

Sending communications (email, messages) to external recipients
Writing to production databases or external systems
Executing commands on external servers
Financial transactions or API calls to payment systems
Deleting data in MCP memory or connected systems
Accessing systems not in the configured tool list

7. Known Limitations and Error Rates

Accuracy: Accuracy depends on the models you configure and varies significantly by task domain and complexity. No model is always right — that is exactly why the approval and audit floors exist.
Hallucination: Like all large language models, ORA agents may generate plausible-sounding but incorrect information. Always verify agent outputs for factual claims.
Context limits: Agents may lose track of instructions in very long sessions or complex multi-step workflows.
Tool failures: External tool calls may fail due to network issues, API changes, or rate limiting. ORA logs but does not automatically retry failed tool calls.
Bias: Underlying models may reflect biases present in their training data. Critical decisions should not rely solely on agent outputs.

8. Audit Trail

ORA logs every action, tool call, governance decision, and human approval or override. Records include: timestamp, action type, decision outcome, human intervention if any, and result — hash-chained and signed so any rewrite is detectable. The audit trail lives on your own machine, under your control, and is append-only: it only ever grows. You can read it at any time from the ORA workspace.

9. Human Override and Stop Mechanisms

You can stop ORA at any time:

Stop everything button: One click halts anything ORA is doing, instantly
Kill switch: Blocks all execution until you explicitly turn it back off
Authority level (A0–A5): Sets the maximum scope of autonomous action — down to advise-only
Egress lock: Shuts the governed shell’s internet lane so nothing can leave the machine

10. High-Risk Use Prohibition

ORA is not designed or validated for use as a sole automated decision-making system in high-risk applications including: medical diagnosis or treatment decisions, credit or employment decisions affecting individuals, law enforcement targeting, critical infrastructure control, or any application where agent error could cause death or serious physical harm. Use in these contexts without appropriate human oversight and validation is prohibited by our Acceptable Use Policy.

11. NIST AI Risk Management Framework Alignment

ORA’s design is aligned with the NIST AI Risk Management Framework (RMF), which provides safe harbor in Colorado (SB 24-205) and affirmative defense in Texas (TRAIGA). Our alignment includes:

Governance: Constitutional rules file plus A0–A5 authority levels, enforced by a fail-closed broker
Mapping: Mission scoping defines the intended use and limitations of each deployment
Measurement: Audit logs provide performance and error measurement
Management: Human oversight mechanisms, stop controls, and scrutiny modes

A full NIST AI RMF alignment report is available at Risk Assessment.

12. EU AI Act Compliance Status

Under the EU AI Act (effective August 2, 2026), ORA is assessed as a Limited Risk AI system (not Annex III high-risk). This classification is based on ORA’s role as an orchestration platform used by businesses for their own workflows, not as a system making decisions that directly affect individuals’ rights or opportunities.

As a limited risk AI system, ORA is required to maintain transparency with users (this document) and ensure humans are informed they are interacting with AI. We do not claim EU AI Act high-risk classification compliance at this time, and users who deploy ORA for high-risk applications within EU jurisdiction bear responsibility for applicable compliance.

13. Contact

Questions about ORA’s AI systems, governance, or this transparency statement: [email protected]