CocoPlus in Context

There is a quiet assumption embedded in most developer tooling: the world is predictable. Write a function, test it, deploy it. Same inputs, same outputs, always. The artifact is deterministic. Done means done.

Data engineering breaks this assumption in multiple places simultaneously. CocoPlus is designed specifically for the world that results from those breakages.

---

What Coco Brings. What CocoPlus Adds.

Cortex Code CLI is not a code editor with AI autocomplete bolted on. It is an agentic shell that operates against a live Snowflake environment — it can introspect your schemas, execute SQL, run notebooks, query your data, and reason about governance, all in a single terminal session.

But Coco, by default, is stateless across sessions. Each session is a fresh start. The environment knowledge accumulated in Tuesday's session is gone by Thursday. The decisions made during the Plan phase are not automatically available during Build. The patterns discovered during one project do not propagate to the next. The safety behavior depends on prompts in flight — and prompts can be worked around.

CocoPlus is the layer that makes Coco stateful, structured, and safe across the full lifecycle of a data project. Not by replacing what Coco does well — but by extending it with exactly what it lacks.

CocoPlus is not a workaround for Coco's limitations. It is an amplification of Coco's strengths, built using Coco's own native extension mechanisms — the same hooks, skills, and subagents that Coco exposes for exactly this purpose.

---

The Data Project Is Not a Software Project

This is the foundational difference. Everything else follows from it.

In a software project, the artifact is code. Code is deterministic: given the same inputs, it produces the same outputs. You can test it in isolation. You can version it completely. You can roll it back cleanly. The environment it runs in is typically something you provision — it can be spun up fresh, torn down, and rebuilt.

In a data project, the environment is not separate from the artifact — the environment is the artifact. You are building schemas that hold live data. You are creating semantic models that define how business concepts are measured. You are deploying AI functions that will be called by production processes. The work product and the production environment are the same thing.

This changes everything about how you must approach development:

Testing Is Not Binary

A unit test passes or fails. A data pipeline produces outputs with a quality distribution. An AI function's accuracy ranges from 60% to 95% depending on data characteristics. "Does it work?" is the wrong question. The right question is: "Does it perform within acceptable bounds for this data distribution?" That requires evaluation infrastructure, not test cases.

Rollback Is Not Clean

Reverting a code commit restores the code. It does not restore data that was transformed and loaded. It does not un-drop a schema. It does not reverse the effects of a migration that ran on 50 million rows. Some operations are irreversible in ways that no git reset can address. This is why CocoPlus treats the distinction between reversible and irreversible operations as an architectural concern, not a developer preference.

Parallelism Has Data-Structure Conflicts

If two engineers work on separate software features and merge them together, git handles the conflicts. If two data engineering agents modify the same schema in parallel — one adding a column, one redefining a view that depends on that column's type — the conflict is not in files. It is in the live database state. And it may produce silent failures: the view still exists, but it now returns incorrect results for a reason that isn't visible without deep inspection.

The Environment Is Not Yours to Provision

Software developers typically have clean development environments — fresh databases, isolated instances, controlled test fixtures. Data engineers often work against environments that already contain production data, real business processes, and shared infrastructure. The target of your work is also the system other people are depending on. Mistakes have immediate, real consequences.

Governance Is Intrinsic, Not Added

In software, security review is something that happens to code before it ships. In data engineering, governance is embedded in the work itself: column-level masking policies, row access policies, PII handling in AI function prompts, data classification tags, cross-region data transfer constraints. A Snowflake AI function that sends masked columns to an LLM is not just a security issue — it is a violation of the data contract that protects that column. You cannot separate "building the function" from "knowing what the function is allowed to do."

---

The Determinism Problem in Data Development

Software engineers reason about code because code is the deterministic part. Data engineers must reason about something harder: a system where the code is only one of many variables.

Consider an AI function built on AI_COMPLETE. The same SQL function called with the same prompt today and in three months may produce measurably different outputs — because the underlying model was updated. The same function called against training data and production data may produce different accuracy profiles — because data distributions diverge. None of this is a bug. It is the nature of probabilistic systems.

But it means that "the function works" is not a stable truth. It is a snapshot. A snapshot that must be re-verified when data distributions shift, when models update, when call volumes change.

This probabilistic core creates a temptation: give up on rigor. Accept that AI outputs are approximate. Ship something that seems to work and monitor it in production.

CocoPlus takes the opposite position.

CocoPlus implements process determinism through three mechanisms:

Checkpoint-Gated Stage Transitions

A CocoFlow stage does not proceed to the next stage because an agent reports that it is done. It proceeds because specific checkpoint files exist with valid content. The transition condition is a file check, not a language model assertion. Checkpoints make completion verifiable by inspection, not by belief.

Hard Technical Gates for Irreversible Operations

The Safety Gate's PreToolUse interceptor does not ask the language model whether a DROP TABLE is appropriate. It reads the SQL, recognizes the pattern, and blocks the call. This happens before any reasoning. It cannot be prompted around. The behavior is unconditional — the same input always produces the same output. This is what "hard gate" means: not "strongly discouraged" but "technically prevented."

File-Based State as the Source of Truth

All CocoPlus state lives in files. AGENTS.md reflects the current phase because a hook wrote to it, not because an agent remembers. The pipeline status in flow.json is accurate because the SubagentStop hook updated it, not because the executing agent reported it. Files are static, inspectable, and diffable. Session memory is dynamic, ephemeral, and context-dependent. CocoPlus treats the former as authoritative and the latter as disposable.

---

Contained Orchestration: Why Locality Is a Feature

Modern orchestration systems typically operate on distributed infrastructure. State lives in a central service. Events flow through message queues. Logs accumulate in monitoring platforms.

This works well for software deployment pipelines because the artifact being deployed (code) is separate from the runtime environment. The pipeline operates on code; the environment is independently stable.

For data projects, this model breaks down. The orchestration system and the environment are deeply entangled. When your orchestration decides to run Stage 4 because Stage 3's checkpoints passed, it is making a decision that will directly modify the live database. The orchestration's state must be readable in the same audit trail as the Snowflake operation logs. Separating them creates a reconciliation problem.

CocoPlus uses contained orchestration. All orchestration state lives in .cocoplus/ and git history. Nothing outside.

The flow.json file is the pipeline definition and the execution log simultaneously. It specifies what should run and records what did run. A developer who wants to understand what happened to their Snowflake environment during yesterday's build session can read two things: the git log and flow.json. These are local files, readable with any text editor, correlatable without a logging platform.

This locality is not a constraint born of technical limitation. It is a deliberate choice about where the source of truth should live. When something goes wrong in a data pipeline, you need to debug it. Debugging a distributed orchestration system requires correlating logs across multiple services with different retention policies. Debugging a local file-based system requires opening three files.

Contained orchestration also means the system works identically in any environment: a developer's laptop, a team's shared workstation, a CI server. No infrastructure to provision, no services to configure, no external dependencies to authenticate.

A system whose state you can read is a system you can reason about. The .cocoplus/ directory is designed to be legible at all times. When the system is opaque — when state lives in services that require authentication to inspect — the developer is not in control. They are a passenger.

---

The Snowflake-Specific Gap CocoPlus Fills

Snowflake Cortex is not a general-purpose database with AI features appended. It is an AI operating layer built into a data platform — and the implications of that specific architecture matter for how you build on it.

When you build AI_COMPLETE functions, you are building probabilistic policies, not deterministic code. The function specifies a behavior; the model approximates it. The accuracy of that approximation is a function of prompt design, model selection, data distribution, and token budget. Testing it means running evaluations against representative data, not writing assertions.

When you build Cortex Analyst semantic models, you are defining how natural language questions map to SQL. The quality of that mapping is not binary — it is a distribution across question types, and it degrades gracefully (or catastrophically) in ways that depend on model reasoning, not code logic.

None of the general-purpose AI developer tools were built for this terrain. CocoPlus was built specifically for the terrain where the development artifact is an AI-powered data product operating inside Snowflake's security boundary — where governance, cost, quality, and safety are not separate concerns but faces of the same problem.

The eight specialist personas reflect the actual roles that Snowflake data teams play: the engineer who builds the infrastructure, the analytics engineer who defines meaning, the data scientist who builds the models, the steward who maintains governance, the CDO who makes architectural decisions. These are not generic software roles renamed. They are roles that exist because building on Snowflake Cortex requires domain-specific expertise at each layer.

The goal of determinism in data development is not to make AI outputs predictable — it is to make everything around AI outputs auditable, repeatable, and improvable. You cannot guarantee the output. You can guarantee the process.