Effective date: July 4, 2026
Human Accountability
OCO systems are designed around accountable human ownership. Automation, AI assistance, pipelines, deployment tools, and operating interfaces may support the work, but they do not remove the need for a responsible person to approve scope, release, access, disclosure, and residual risk. Important decisions must have a review path, an owner, and a way to stop or correct the system when the operating context changes.
For OCO, accountability is practical: a system owner must know what the system is allowed to do, what it is not allowed to do, who can approve changes, what evidence supports a decision, and when a human must intervene. This applies to internal tools, client systems, public ventures, AI-assisted workflows, security operations, and deployment processes.
Project Boundaries
Each project should identify what is public, private, internal, client-owned, partner-owned, research-only, pre-release, or approved for disclosure. OCO separates public website language from private operating records, private datasets, security-sensitive architecture, credentials, client material, and unreleased systems. A public description of a capability does not mean that the underlying data sources, implementation details, access controls, or client work are public.
Boundary work is done before publishing, integrating, or automating. A project may have public marketing text, private engineering records, restricted datasets, limited-access APIs, private deployment notes, and owner-only security findings at the same time. OCO keeps those layers separated so public communication does not accidentally expose controlled operational material.
Evidence Records
When evidence matters, OCO records decisions, approvals, release states, review notes, security findings, model evaluations, data lineage, and change history in a way the owner can inspect. Evidence records are not decoration. They support accountability, incident review, audit readiness, correction paths, and public transparency when a system is intentionally designed to expose part of its record history.
Evidence does not need to make every record public. In many cases the correct design is to record enough internal proof for review while exposing only a controlled summary to users, auditors, customers, or the public. The governance decision is what should be provable, who can inspect it, how long it should be retained, and how corrections or disputes are handled.
AI and Automation
AI and automation are scoped by purpose, source boundaries, model limits, evaluation method, user role, and review requirement. OCO may use AI-assisted engineering, research, drafting, testing, analysis, or workflow automation, but AI output is treated as material that may require review, validation, correction, and human approval before it is relied on for important decisions or public release.
OCO separates AI suggestion from operational authority. A model may help classify, summarize, draft, test, compare, or interpret information, but the surrounding system still needs source limits, refusal boundaries, evaluation records, user permissions, logging, fallback behavior, and a clear rule for when the output becomes only advisory until reviewed.
Security and Access
Governance includes security posture: environment separation, least privilege, credentials handling, access logs, change review, incident paths, backup and recovery expectations, and written authorization for testing. OCO does not treat security review as permission for open-ended probing. Testing must be scoped, approved, documented, and handled without exposing exploitable detail in public channels.
Security governance is also release governance. Before a system becomes production-facing, OCO expects the environment, secrets, branches, deployment path, access model, monitoring, backups, and rollback process to be understood. The same governance mindset applies to authorized testing: validation is useful only when it is scoped, controlled, recorded, and followed by remediation decisions.
Changes and Contact
Governance practices may change as OCO systems, clients, ventures, providers, laws, and operational risks change. Public governance language is intentionally high level and does not disclose private operating controls, internal records, client material, or sensitive security detail. Governance questions can be sent to info@oco.io.
This public page is not the full internal governance program. It is the public explanation of the principles OCO uses when describing systems, releasing public material, and separating approved disclosure from private work. More specific obligations may appear in contracts, scopes, security reports, deployment runbooks, or project records.