Product Development Philosophy

This document describes the product development philosophy for the open-source Monkeys ecosystem. It is not a roadmap, a deployment guide, or a feature specification.

Monkeys should be developed as a data-centered, AI-native product system. Studio, Kernel, Compute, agents, workflows, tools, and services should not become separate islands. They should operate around the same data model, the same business semantics, and the same product contracts.

Core Idea

Data is the first-class product object in Monkeys.

Pages, workflows, tools, and agents are different ways to create, transform, present, or act on data. They are important user and developer experiences, but they should not become the stable center of the architecture. The stable center is the data structure, the semantic model, the access contract, and the execution model around it.

The core data model should be understood this way:

• Global Data is the organization-level full historical fact layer.
• Ontology defines business semantics.
• Filter and View define access, selection, and presentation.
• Studio, Kernel, Compute, and agents generate, compute, display, edit, and act around the same fact layer.

Global Data is not a user-facing business label that every screen needs to expose. Users may see data repositories, datasets, views, workspaces, tasks, and generated results. The system uses Global Data to keep facts unified, governable, queryable, and reusable by product surfaces and agents.

Product Principles

1. Start From Data, Not Pages

Every feature should begin with data questions:

• What data does this feature create?
• What data does it consume?
• What business object or ontology does it belong to?
• What state changes does it introduce?
• Can the result be reused by agents, workflows, Compute, or another product surface?

A page is one interaction surface for data. A workflow is one execution path for data changes. An agent is one actor that can operate on data. The product should stay coherent even when any single interface changes.

2. Put Business Variation Into Data And Configuration

Monkeys should avoid hardcoding business rules for a single customer, project, or page.

Business variation should be expressed through ontology definitions, view configuration, workflow configuration, tool configuration, workspace configuration, and other declarative data. Code should provide stable runtimes, protocols, components, and extension points.

This keeps the product open-source friendly: developers can extend the system by adding data, configuration, tools, and product modules instead of forking scenario-specific logic into the core.

3. Treat Global Data As The Unified Fact Layer

Global Data is the organization-level full historical fact layer. It supports reuse across ontologies, views, applications, workflows, and agents.

Global Data should make product behavior more coherent:

• Data can be aggregated across product surfaces.
• Agents can operate on unified facts instead of fragmented page state.
• Compute can run on the same facts that Studio and Kernel expose.
• Governance, permissions, lineage, and querying can be handled consistently.

Global Data should remain a system concept with clear responsibilities. Product screens should expose the right user-facing abstraction instead of forcing internal terminology into the interface.

4. Use Ontology As The Business Language

Ontology is how Monkeys describes the business world. It should not be treated as only a bucket, table, or storage detail.

Different industries, departments, workflows, and design stages need different business objects. Ontology turns raw records and fields into objects that Studio, Kernel, Compute, tools, and agents can understand together.

Without ontology, data is only records and fields. With ontology, data becomes a shared business language.

5. Keep Studio, Kernel, And Compute Distinct But Connected

Studio, Kernel, and Compute are not isolated products. They are three interfaces over the same data-centered architecture.

• Studio is the user-facing creation and operation surface. It helps users create, edit, organize, and use data in natural workflows.
• Kernel is the governance and control surface. It manages ontology, Global Data, permissions, models, tools, configuration, and workspaces.
• Compute is the execution and automation surface. It turns data into long-running tasks, workflow execution, model calls, agent actions, and background computation.

The three surfaces should share product concepts and data contracts. A feature that exists in one surface should not invent a separate hidden model if the same concept already exists in the shared data architecture.

6. Make Agents First-Class, But Keep Data As The Contract

Agents should be able to read data, write data, call tools, trigger workflows, generate deliverables, and move business state forward.

But agents should not bypass the product model. Their actions should be constrained by ontology, views, permissions, workflow contracts, tool contracts, and runtime policies. This makes agent behavior explainable, auditable, reusable, and suitable for serious production scenarios.

The goal is not to make agents magical. The goal is to make product data and product actions structured enough that agents can safely use them.

7. Build For Open Source And Enterprise-Grade Complexity

Monkeys is an open-source ecosystem. It should be useful to global developers as a complete product system for teams and organizations, while still being strong enough for complex enterprise scenarios.

That means:

• Core concepts must stay stable.
• Modules must be composable.
• Configuration must be declarative.
• Product behavior must be explainable.
• Data contracts must be reusable.
• Customer-specific learning should become standard product capability whenever possible.

The product should not become a collection of one-off projects. Enterprise scenarios should strengthen the open-source architecture instead of pulling it apart.

Engineering Implications

When adding or changing product behavior, prefer these defaults:

• Define the data model before the interface.
• Reuse existing ontology, data, view, workflow, and tool contracts before creating new ones.
• Put business rules into declarative configuration when possible.
• Keep user-facing labels separate from internal system concepts.
• Avoid duplicating state across Studio, Kernel, Compute, and backend services.
• Make agent-readable APIs explicit, typed, and permission-aware.
• Keep implementation details local to the owning repository, but keep shared concepts documented at the ecosystem level.

One-Sentence Version

Monkeys is developed around organization-level full historical facts: Ontology defines business semantics, Filter and View define access and presentation, and Studio, Kernel, Compute, and agents work around the same data contracts so the product can remain open-source, composable, and strong enough for complex enterprise work.