Documentation

The CRM model

The object set is fixed. That is the constraint the whole product rests on: an agent writing into a fixed, well-named model produces something another agent can read, and a human can inspect. A schema an agent can invent produces a database only that agent understands.

The objects

Company	An organization. Matched on a normalized domain, never on name similarity.
Contact	A person. Matched on a normalized email, never on name similarity.
Opportunity	A deal in a pipeline stage. Status is derived from the stage.
Interaction	A summary of something that happened, with its actor and assertion kind.
Task	A follow-up, optionally due and linked to records.
Pipeline and stage	Ordered stages with a kind: open, won, or lost.
Source	Where an assertion came from, when there is one.
Actor	Who or what made a change. One per credential.
Mutation and field change	The append-only record of every write and its diff.

What you can configure

Custom object types, with typed fields and declared relationships
Pipeline names and their ordered stages
Stage labels, kind, and optional probability
Custom fields on company, contact, opportunity, and task
Tags
Relationship roles on known associations
Lifecycle labels mapped to a canonical category
Workspace display timezone and default currency

What you cannot

These are deliberate limits, not missing features. Naming them saves you looking.

The canonical object set: a company is a company in every workspace
Pipeline semantics on your own types, so forecasting stays comparable
Identity resolution on your own types, which rests on email and domain
Replacing core identifiers or timestamps
Computed or code fields
A workflow engine
Arbitrary graph edges between unknown objects
Custom storage schemas or raw SQL

Standard fields are real columns

Not an attribute table, not a JSON blob. A company's name is a column called name, which is why search, sorting, and constraints behave the way you expect rather than the way a generic schema forces.