Skip to content
OpenCOOS

The Standard

Common Ownership Operating Schema

The Common Ownership Operating Schema (COOS) defines how strata information is named, structured and related, so that it can be represented and exchanged consistently across software platforms and industry initiatives.

Key facts

What it is
An open, vendor-neutral data model for shared-ownership communities. A data standard, not a software product.
Coverage
Strata in BC; condominiums in Ontario, Alberta and across Canada
Status
Early development · working draft v0.1.0-draft
Format
JSON Schema (2020-12) with example payloads
Licence
Apache-2.0: free for commercial use
Maintained by
OpenCOOS, an open initiative founded by ManageStrata

Working draft v0.1.0-draft — not yet released

The domains below are proposed. Entities marked Proposed or Experimental have draft schemas that may change; entities marked Planned have no schema yet. Provincial legal terminology is used carefully and flagged for review before it becomes normative. Nothing here is legal advice.

Scope

What the standard is — and is not

In scope

  • Definitions of strata entities, fields, relationships and controlled vocabularies
  • Machine-readable JSON Schemas and example payloads
  • Conventions for identifiers, dates, money, addresses and extensions
  • Versioning, deprecation and compatibility rules
  • Strata and condominium corporations across Canada: BC first, then Ontario and Alberta

Out of scope

  • A hosted API, database or software product
  • Storing or publishing any strata corporation's data
  • Legal interpretation or compliance determinations
  • Mandating how implementers store data internally

Specification domains

Proposed initial domains

Stable
Part of a published release. Changes follow the deprecation policy.
Proposed
Drafted and open for review. May change before a release.
Experimental
Early draft that needs implementation feedback. Likely to change.
Planned
Identified for future work. No schema has been drafted yet.

See how terms map across provinces in jurisdictions and terminology. All entities use the shared definitions for identifiers, dates, money, addresses and extensions.

Design principles

How decisions are made

Open by default
Public specifications, transparent documentation and an open development process.
Interoperable
Different systems can exchange and interpret information consistently.
Canadian and jurisdiction-aware
Reflects the terminology, governance and regulatory context of each province, starting with BC strata and Ontario and Alberta condos.
Community-driven
Developers, councils, managers, researchers and industry participants can all contribute.
Practical
Starts with real-world strata workflows and evolves through implementation experience.
Extensible
Namespaced extensions support future integrations, automation, analytics and AI.
Vendor-neutral
No dependency on a single software provider or technology stack.
Privacy-conscious
Defines structures without requiring disclosure of private or sensitive strata information.

Terminology

Terms used in the specification

Entity
A kind of thing the standard describes, such as StrataLot or Resolution. Each entity has one JSON Schema.
Field
A named property of an entity, with a type, description and constraints.
Shared definition
A reusable type such as Money or Address used by many entities.
Controlled vocabulary
A fixed list of permitted values for a field, each with a definition.
Relationship
A field whose value is the identifier of another entity.
Extension
Implementation-specific data kept under a reverse-domain namespace, outside the standard.
Normative / informative
Normative text is a requirement of a release. Draft definitions and examples are informative until released.

Strata terms such as strata lot, common property, unit entitlement and contingency reserve fund are currently used in their BC sense; see the terminology crosswalk for Ontario and Alberta equivalents. Definitions in the draft summarise common usage and are marked for legal review.

Versioning

How releases are identified

MAJOR.MINOR.PATCH

Releases follow semantic versioning. Breaking changes increase the major version.

0.x and -draft

Until 1.0.0, any release may contain breaking changes. Drafts carry a -draft suffix.

/spec/{version}/…

Each version's schemas are published at a stable URL that does not change.

Versioning and compatibility policy