Causality Reference

Every modelling decision in Mockomat has consequences further down the line: in the mock API your consumers call, in the data it returns, and in what you export. This page documents those chains, so you can predict the effect of a change before it reaches your consumers.

---

Model to API

Model Decision	Mock API Consequence
Table created	Default operations named after the table, e.g. customers (list) and customer (detail) for Customer
Attribute name	The field name in responses
Attribute type	No effect on responses — send parameter values in the type the data holds (numbers without quotes)
Searchable flag	The field is searched by searchTerm in list operations
Sortable / Filterable flag	No effect on the mock API: sortField accepts any attribute bound to a data column, and filtering uses operation parameters
Required flag	No effect on the mock API; the OpenAPI export lists the attribute as required

Renaming an attribute changes the field name consumers receive. Default operations take their names from the table when they are created; rename operations in API Design. Treat names as stable contract identifiers once consumers have integrated.

See Tables & Attributes for the full attribute reference.

ref-causality-01-model-to-apiMissing

Attribute settings on a table and their effect on the mock API.

---

Model to Runtime

Model Decision	Runtime Consequence
Table bound to imported data	The list operation returns rows of the data pool
Table not bound	An empty list and a NOT_READY error
Relation between tables	Related records are included, one level deep, at most 50 per parent record
Relation cardinality (1:1 vs 1:n)	Response shape: a single nested object vs an array of objects
Relation direction	Which table exposes the nested data in its queries
Relation with wrong linking columns	Empty nested fields

See Relations for cardinality and direction, and Runtime for the query pipeline.

ref-causality-02-model-to-runtimeMissing

Relation drawn on the board and the nested data in the query result.

---

Mapping to Data

Mappings control where field values come from. The mapping type is invisible to API consumers — they receive the same response shape regardless of how the data was sourced.

Mapping	Data Consequence
Data Source (SOURCE)	The value of the imported row's column; stable and consistent with related rows
Constant (CONSTANT)	A fixed value on every row, on rows of imported data and on rows composed from value pools alike
Computed (COMPUTED)	Not part of the response — the runtime does not evaluate expressions; the attribute editor no longer offers Computed
No column bound	No value for the field

The runtime never invents values: as long as the pool data is unchanged, the same query returns the same data. That makes Data Source mappings suitable for integration tests with expected outputs.

See Data Sources for the full mapping workflow.

ref-causality-03-mapping-to-dataMissing

Mapping configuration with Data Source and Constant attributes and their runtime output.

---

Operations to Consumer

API Design defines how consumers query a table.

Operation Setting	Consumer Consequence
Operation name	The root field consumers query
Default page size	Applied when the consumer sends no pageSize (at most 100)
Default sort	Applied when the consumer sends no sortField
Parameters	The arguments consumers can filter by; an unknown or missing required argument answers BAD_USER_INPUT
Scope filters	Conditions that always apply, combined with parameters by AND

Views shape the runtime preview in the app (which columns show, in which order). They do not change the mock API response, which always carries every mapped attribute.

See Views and API Design.

ref-causality-04-view-to-consumerMissing

Operation settings and the resulting query behavior side by side.

---

Model to Export

Model Decision	Export Consequence
Table	One module per table in a code package; one schema in the OpenAPI export
Attribute name and type	Property, column and field types
Required flag	A required property in the OpenAPI export; not applied in code packages yet
Searchable / Sortable flags	Search fields and sortable list columns of the generated list query
Relation	Part of the OpenAPI export; not generated in code packages yet
Operations and parameters	Not part of exports — code packages come with their own standard queries and mutations per table

See Export for the generation workflow and output structure.

ref-causality-05-api-to-exportMissing

Model elements and where they appear in the OpenAPI export and the code package.

---

Plan to Features

Your account plan determines the feature surface available to your team.

Plan	Key Consequences
Guest	Temporary project kept in the browser; endpoint opened by its share token; no team
Starter	Persistent project; mock API in the app only (no API keys); only you as member; daily request quota
Professional	API keys for your own code; team roles; code export; monthly request quota
Business	More projects, members and maintainers; endpoint analytics
Enterprise	No catalog limits on projects and requests; limits per contract

The plan boundary is enforced by the platform. Creating an API key on Starter, for example, fails with a plan restriction — the project's mock API stays closed to your own code rather than falling back to a public endpoint.

See Account and Plans for all limits.

---

Role to Access

Roles govern what each team member can do in the projects they can open.

Role	Access Consequences
Readonly	Sees projects, the model and the preview; reads board notes
Reporter	Also writes board notes and comments
Editor	Also builds the model, creates projects, manages API keys and runs code export
Maintainer	Also deletes projects and manages members, project access and workspaces

The owner of the account is a maintainer and manages billing. Role restrictions are enforced by the API, not only in the interface: an Editor who tries to delete a project through a direct API call receives an authorization error.

See Team & Roles for the full permission list.

---

Preview Hint Chains

Trigger	Runtime Effect	Hint in the Preview
Table not bound to imported data	No rows	Not mapped to imported data
View not bound to a list operation	No data loads	No API binding
View without identifier field	Rows open no detail view	No identifier field

See Preview & Hints.

ref-causality-06-hint-chainsMissing

Runtime preview showing a hint and the place to fix it.

---

Cross-Cutting Chains

From Table Creation to API Consumer

1. Table created on the Modelling Board — default operations are created with it.
2. Attributes configured in Tables & Attributes — names and types defined.
3. Table and attributes mapped in Data Sources — the table reads rows of the data pool.
4. Operations tuned in API Design — names, parameters and defaults.
5. Consumer queries the endpoint — the Runtime returns the mapped data.

From Relation to Nested Query

1. Relation drawn on the Modelling Board.
2. Cardinality selected — an object (1:1) or an array (1:n) in the response.
3. Direction set — which table exposes the nested data.
4. Consumer selects the nested field — the runtime includes the related records, one level deep.

Changing the cardinality after consumers have integrated changes the response shape (object vs array) — a breaking change.

ref-causality-07-cross-cuttingMissing

End-to-end flow from table creation through mapping to the consumer query.

---

Summary

When evaluating a modelling change, trace the chain forward:

• Will this rename break existing consumer queries? (Model to API)
• Is the table still bound to imported data? (Model to Runtime)
• Will this attribute still return a value? (Mapping to Data)
• Do consumers rely on this operation, parameter or default? (Operations to Consumer)
• Does the export carry what I expect? (Model to Export)

If the answer to any of these questions is uncertain, use the Modelling Runtime Preview to validate before committing the change.