Product Data Assembly Guide

This guide describes how to assemble a data-driven product experience in Monkeys. It connects product usage with the technical concepts in Key Technical Concepts.

The goal is not to configure pages one by one. The goal is to assemble a product system where data can be configured, collected, interacted with, edited, and actively reused by workflows, tools, Compute, and agents.

Who This Guide Is For

Use this guide when you need to:

• Prepare data for a Studio application.
• Turn business objects into an ontology-backed data model.
• Configure views and filters for data interaction.
• Connect data with workflows and tools.
• Persist generated outputs back into product data.
• Check whether a feature is assembled around stable data contracts.

This guide uses public Monkeys concepts only. It does not describe custom packaging or deployment-specific implementation details.

Assembly Flow

1. Model The Data

Start by defining what business objects the product needs to understand.

Questions To Answer

• What are the core business objects?
• Which objects need to be stored as records?
• Which fields are required, optional, derived, or generated?
• Which fields are used for filtering, sorting, grouping, or search?
• Which objects are produced by workflows or agents?
• Which files or generated outputs carry business meaning and should become artifacts?

Recommended Output

Produce a short data model note before building UI:

## Data Model

Object: Product Idea
Purpose: Store design inspiration and structured product planning inputs.

Fields:
- title: text, required
- description: rich text, optional
- category: enum, required
- source_images: artifact list, optional
- tags: tag list, optional
- status: enum, generated or user-edited
- created_from_workflow_id: reference, optional

Primary views:
- All ideas
- Ideas by category
- Ideas ready for workflow

Good Signs

• The object can be explained without referring to one screen.
• Fields have stable technical identifiers and friendly display labels.
• Generated outputs have an artifact strategy.
• The same model can be used by Studio, Kernel, workflows, tools, and agents.

Common Mistakes

• Starting from a page layout before defining records.
• Creating separate schemas for import, display, workflow input, and agent output.
• Using display labels as stable identifiers.
• Treating generated files as unrelated to the data model.

2. Define Ontology And Schema

Ontology gives business meaning to data. Schema gives structure to each object.

What To Define

For each ontology-backed object, define:

• Object name: The stable product concept.
• Fields: Technical identifier, display label, type, required state, default value.
• Relations: Links to other records, artifacts, workflows, tools, or users.
• Lifecycle state: Draft, ready, running, generated, approved, archived, or other meaningful states.
• Validation rules: Required fields, allowed values, file constraints, numeric ranges.
• Derived fields: Values calculated from other fields or external execution.

Field Types To Consider

Assembly Rule

If a field controls workflow behavior, agent behavior, permissions, filtering, or generated output, it should be modeled explicitly. Do not hide it only inside a prompt, page component, or task script.

3. Configure Data Repositories

A data repository is the user-facing place where a set of records can be managed. Internally, it should still follow ontology and Global Data contracts.

Configuration Checklist

• Choose or create the repository for the object.
• Bind the repository to the intended ontology.
• Confirm which fields are visible, editable, read-only, derived, or hidden.
• Decide how artifacts are uploaded, displayed, and linked.
• Define default sorting and grouping.
• Define search behavior.
• Confirm which records are available to workflows and agents.

Repository Design Guidance

Keep repositories understandable for users:

• Use business names instead of system terms.
• Show only fields that help the workflow.
• Keep advanced configuration in Kernel-facing surfaces.
• Make generated artifacts visible near the records that produced them.

Keep repositories stable for the system:

• Persist facts in shared data contracts.
• Avoid storing business state only in view-local UI state.
• Keep record identifiers stable across import, generation, and editing.

4. Configure Views And Filters

Views define how data is inspected and operated on. Filters define how data is selected.

View Types

Filter Design

Each reusable filter should define:

• Source object or repository.
• Field predicates.
• Search behavior.
• Tag matching behavior.
• Permission-aware selection rules.
• Default sorting.
• Empty-state behavior.

Good View Design

A good view answers:

• What data am I looking at?
• Why is this record included?
• What can I do with it?
• What happens after I act?
• Where does the result go?

Common Mistakes

• Treating a view as the owner of the data.
• Building the same filter logic separately in Studio, Kernel, API code, and agent tools.
• Creating a new backend concept for every visual variation.
• Hiding workflow status away from the record that triggered it.

5. Collect Data

Data can enter Monkeys through multiple paths. Each path should eventually produce records, artifacts, or structured state that the system can reuse.

Collection Paths

Import Checklist

Before importing data:

• Map source columns to ontology fields.
• Normalize names, categories, units, and enum values.
• Decide how duplicates are detected.
• Decide how artifacts are attached.
• Preserve source metadata when useful.
• Validate required fields before records become active.

After importing data:

• Check record counts.
• Inspect failed rows or skipped files.
• Verify search and filters.
• Open at least one table view, one detail view, and one workflow input path.
• Confirm generated or imported artifacts are linked to records.

6. Interact With Data

Interaction is how users and agents inspect, select, compare, and prepare data for action.

Interaction Patterns

• Browse records through table, card, gallery, or detail views.
• Filter by fields, tags, status, stage, date, or ownership.
• Select records as workflow inputs.
• Compare records side by side.
• Open artifacts and generated outputs.
• Inspect lineage and action history.
• Save useful subsets as views.

Interaction Design Rules

• Keep the user's task visible.
• Make selection state explicit.
• Show why a record is included in a filtered view.
• Show whether a record is editable, generated, locked, or derived.
• Avoid forcing users to understand internal system terminology.

7. Edit Data

Editing should be treated as a data change with validation, state, and traceability.

Edit Sources

Edit Checklist

Before allowing edits:

• Confirm the field is editable in this context.
• Confirm the user or agent has permission.
• Validate type, range, enum, reference, and artifact constraints.
• Decide whether the edit changes workflow eligibility.
• Decide whether the edit should create an action log entry.

After edits:

• Refresh affected views.
• Update search indexes if needed.
• Recalculate derived fields if needed.
• Preserve links to workflow runs or artifacts that produced the change.

8. Actively Reuse Data

Data becomes more valuable when the product can act on it.

Reuse Modes

Active Reuse Checklist

• Is the input data selected by a view or filter?
• Are required fields present and valid?
• Is the workflow or tool contract typed?
• Is execution state visible?
• Are outputs persisted as records or artifacts?
• Is lineage available from output back to input?
• Can another view, workflow, or agent reuse the output?

9. Persist Results And Lineage

Generated results should not disappear into logs, prompts, or one-off files. If they matter to the product, persist them.

What To Persist

• Final records created by workflows or agents.
• Generated artifacts such as files, images, documents, or model outputs.
• Execution state and terminal result.
• Source inputs and selected records.
• Tool calls and important parameters.
• Review, approval, or rejection decisions.

Lineage Questions

For any important output, the product should be able to answer:

• What input records produced this?
• Which workflow, tool, or agent created it?
• When was it created?
• What version of the workflow or tool was used?
• Was it edited after generation?
• Which view or repository now exposes it?

End-To-End Example

This example uses a generic product inspiration workflow.

Step 1: Define The Object

Object: Product Inspiration

Fields:

• title
• description
• category
• source_images
• material_tags
• design_direction
• status
• generated_outputs

Step 2: Configure Repository And Views

Create a repository named "Product Inspiration Library".

Views:

• "All inspiration": table view with category, status, and tags.
• "Visual browsing": card view with source images.
• "Ready for generation": filtered view where status is ready.
• "Generated results": view showing records with generated outputs.

Step 3: Collect Inputs

Inputs can come from:

• Manual upload of images.
• Structured form submission.
• Imported spreadsheet rows.
• Tool output from an external research source.

Each input becomes a record or artifact linked to a record.

Step 4: Trigger Workflow

The "Ready for generation" view becomes the workflow input source.

The workflow:

• Reads selected records.
• Calls tools or model tasks.
• Produces generated artifacts.
• Writes status and output links back to the original records.

Step 5: Review And Reuse

Users inspect generated outputs in Studio. Agents or workflows can later reuse the same outputs for ranking, reporting, refinement, or another generation step.

Quality Checklist

Before considering a data assembly complete, verify:

• The ontology and fields can be explained without referencing one page.
• Data can be imported or created consistently.
• Views expose the right interaction patterns.
• Filters are reusable and permission-aware.
• Workflows can consume records through stable contracts.
• Generated artifacts are persisted and linked.
• Edits are validated and traceable.
• Agents can understand the data contract without relying on hidden UI state.
• The result can be reused by another workflow, view, or product surface.