Platform
What a unit record contains
A Sakneen unit record describes one home across nine groups of fields: identity, geometry, specification, position, commercial terms, availability, delivery, warranty and community. Each field has one owner — the developer, the sales system or the buyer — and one current value that every product reads.
The record schema
Every field below exists on every unit in Sakneen. Fields marked as developer-owned are maintained by the developer's systems; sales-owned fields change as the unit transacts.
| Group | Fields | Owner |
|---|---|---|
| Identity | Unit code, project, phase, cluster, building, floor, unit number | Developer |
| Geometry | Built-up area, land area, garden area, roof area, terrace area, ceiling height, bedrooms, bathrooms | Developer |
| Specification | Unit type, finishing level, kitchen and bathroom spec, appliances, smart-home fit-out | Developer |
| Position | Orientation, view, aspect, corner or mid, proximity to amenities, plot coordinates | Developer |
| Commercial | List price, price per metre, eligible payment plans, down payment, instalment years, cash discount, maintenance deposit | Developer |
| Availability | State (available, held, reserved, contracted, delivered, released), hold owner, hold expiry, release tranche | Sales |
| Delivery | Contractual delivery date, construction milestone, handover status, snag list | Developer |
| Warranty | Warranty period, covered systems, claim history | Developer, then owner |
| Community | Compound, service charge, community rules, amenity access, management contact | Developer, then owner |
Field availability depends on what a developer maintains. Sakneen does not invent values for fields a developer has not supplied — an empty field renders as empty rather than as a default.
Properties of the record
- Single-valued
- A field has one current value. Every surface reads it rather than caching its own copy.
- Versioned
- Changes to price, geometry and availability are retained, so an offer resolves to the state the unit was in when it was issued.
- Permissioned per field
- A brokerage can see availability and published price without seeing internal cost or discount authority.
- Addressable
- Every unit has a stable identifier used by the API, the MCP server, the masterplan geometry and the CRM sync.
- Portable
- The record survives the transaction: it moves from developer to owner at handover rather than being archived.
- Auditable
- Who changed what, and when, is recorded — which is what makes analytics and finance agree.
Why this table matters more than the software
Software is replaceable; the schema is the durable part. A developer that has agreed what a home is — as a set of fields with owners — can change CRM, change sales agency and change reporting tool without renegotiating the meaning of its own inventory.
Frequently asked questions
- Can we add custom fields?
- Yes. The groups above are the standard record; developers extend it with their own fields, which then appear in offers, filters and the API alongside the standard ones.
- Does the record hold client data?
- The unit record describes the home. Clients, offers and reservations are separate objects that reference it, which keeps personal data out of the record that gets shared with brokerages.
- Is the schema available programmatically?
- Yes, through the API and the MCP server. Both expose the same field names as this table, so the documentation and the payload agree.
Related
See it against your own inventory
Bring one project. We load its masterplan and unit list, and you see your own homes as digital records before you decide anything.