Vavan AI
Vavan Core

Properties

The typed fields that describe an object type, from plain text and money to enums, geo, and derived values.

A property is a typed attribute on an object type. Where an object type defines what a thing is — an Account, an Order, a Route — its properties define what is known about each instance: a name, a balance, a pipeline stage, a coordinate, a timestamp. Properties are the columns of the shared model.

Every property has a name, a type, and a set of constraints (required or optional, a default, an allowed set of values). Because Vavan Core is config-driven, properties are declared once and then enforced everywhere the object is read or written — across apps, integrations, signals, and the in-app assistant. There is no per-app schema that can drift out of sync.

Note. Properties describe a single object. Relationships between objects are modeled separately as link types, and changes to objects are made through governed action types rather than ad-hoc edits.

Property types

Vavan Core supports a fixed set of property types. Choosing the right type is what makes downstream behavior — validation, filtering, formatting, analytics — work without custom code.

Type Description Example
Text Free-form string, optionally length- or pattern-constrained. Account name, contact notes
Number Integer or decimal numeric value. Quantity, headcount, tank capacity
Money / Currency Numeric value paired with a currency code; formatted and aggregated as money. Order total, credit limit, open pipeline value
Boolean True / false flag. is_active, is_at_risk
Date / Timestamp Calendar date or point in time (timezone-aware for timestamps). Created at, last order date, follow-up due
Enum (single-select) One value from a fixed, controlled set defined on the property. Pipeline stage, account type, priority
Geo / Location Latitude / longitude coordinate, optionally with an address. Site location, stop coordinate, vehicle position
Reference A pointer to another object. Useful for lightweight lookups, but proper relationships should be modeled as link types, which carry cardinality and are traversable in both directions. Owner (a User), primary contact
Derived / Computed A read-only value calculated from other properties or related objects. Days in stage, open pipeline value, is at risk
JSON / Structured A nested, structured payload for data that does not warrant its own object type. Integration metadata, raw external record

Required vs optional

Each property is declared as required or optional. A required property must be present whenever an object is created or its value is changed through an action; the constraint is enforced at write time, so incomplete objects never enter the model. Optional properties may be absent, which is distinct from being empty — "unknown" and "blank" are not the same.

Default values

A property may declare a default applied when an object is created without an explicit value. Defaults keep new objects consistent: a new opportunity can default its stage to Lead, a new account can default is_active to true. Defaults are applied by Vavan Core, not by each app, so the behavior is identical regardless of how the object was created.

Enums & controlled vocabularies

An enum property restricts its value to a fixed, named set. Controlled vocabularies are what make the model queryable and the apps consistent — everyone speaks the same language for stages, types, and statuses. The canonical example is the sales pipeline stage:

  1. Lead
  2. Qualified
  3. Fact Finding
  4. Quote
  5. Credit App
  6. Won / Lost

Because the stage set is defined on the property, a value outside it cannot be written, and every report, board, and automation can rely on exactly these stages. Advancing a record through them is itself a governed operation — see action types.

Derived properties

A derived property is computed rather than stored by hand. It is read-only: you change the inputs, and the derived value follows. Derived properties turn raw data into decision-grade signals without each app reimplementing the same arithmetic. Representative examples:

  • Days in stage — computed from the timestamp a record entered its current pipeline stage.
  • Open pipeline value — the summed Money value of an account's linked open opportunities or orders.
  • Is at risk — a Boolean derived from rules over recency, balance, and activity (for example, no order in N days while previously active).

How properties feed signals and analytics

Properties are the inputs to everything above them. Enums and derived values define the columns of boards and dashboards; thresholds over them generate signals (a record whose is_at_risk flips to true, or whose days_in_stage crosses an SLA), which in turn drive recommended actions and tasks. Because the same typed properties are read across every app, analytics computed in one place mean the same thing everywhere — there is one definition of "open pipeline value," not one per tool.

Conceptual example

The following is a conceptual example of a property definition, not a literal API payload:

# conceptual example — property definition on the Opportunity object type
property:
  name: pipeline_stage
  type: enum
  required: true
  default: Lead
  values:
    - Lead
    - Qualified
    - Fact Finding
    - Quote
    - Credit App
    - Won
    - Lost
Note. Every property value is scoped to an organization and protected by row-level security, so one organization can never read or write another organization's objects. See Security for the isolation model.

Next: how object types relate to one another through link types, and how those relationships are mutated through action types.