Core Fields

Every form field in Mockomat is backed by a column in the metadata schema. Core Fields is the canonical glossary of those columns — one page per domain (project, workspace, user, plan, …), with a short prose description of what each persisted attribute means, when it's used, and how it interacts with other fields.

How this connects to the app

Inside the Mockomat app, most edit/create dialogs surface a small Read docs icon next to fields you might want to research. That icon deep-links here, jumping straight to the field's anchor — no scanning required.

Why a separate reference

The Glossary explains concepts — what a "blueprint" or a "relation" is, in plain language. Core Fields explains columns — the bit between the label and the value in the database. It exists because:

• Power users and integrators frequently need to know which exact field drives a behaviour (e.g. "is the slug case-sensitive?", "what happens when I set visibility to true?").
• Support and onboarding conversations are faster when both sides can point at the same anchor.
• The team that builds Mockomat needs a single place to keep the documented contract of each field as the schema evolves.

Sections

Domain	Description
Project	Everything on the project record — name, slug, visibility, preview/collaboration sharing, blueprint-publication metadata, board state.

More domains are on the way. This first release covers the fields users see most often — the projects table and its siblings. Other domains (workspace, user, plan, modelling, mail, …) will be folded in as their dialogs get wired up.

Reading a field entry

Each domain page lists every column of every table in that domain. Rows look like this:

Example row layout

<a id="projects.name"></a> name · string · required

The display name shown in lists, on the board, and on every share link. Treated as opaque text; pick whatever a human would recognise. Renaming is safe — references use the immutable uuid, not the name.

• The bold leading token (e.g. name) is the column name as it appears in the database. The anchor before it (<a id="projects.name">) is the deep-link target the in-app Read docs icon points at.
• The type comes straight from the metadata schema (string, int, enum, datetime, …).
• "required" / "optional" mirrors the column's NOT NULL constraint.
• The paragraph underneath describes the field in product terms — what changes when you set it, what other fields it interacts with.

Scope

Included	Excluded
Persisted columns of the MariaDB metadata schema — projects, workspaces, users, plans, modelling tables, jobs, audit logs, …	The MongoDB mock-data store. Mock data is dynamic per project and is described by your own tables and attributes, not by fixed columns.

For the MongoDB side, see the Modelling docs — your project's schema is whatever your tables describe.