ADR 0031: Standards-aligned groupware domain models
- Status: Accepted design direction; base contact profiles implemented locally, complete profiles and synchronization pending
- Date: 2026-11-04
- Complements: ADR 0014, ADR 0025 and ADR 0027
Context
Section titled “Context”The V1 catalog includes Contacts, Distribution lists, Projects, Cases and Tasks. Appointments and Vacations are later scope; their planned profiles share the temporal foundation with Tasks. Later exchange with contact, calendar and task applications must not require replacing their domain meaning. The existing generic fields and prototype fixtures do not establish interoperable domain profiles. The domain-profile appendix now elaborates proposed starting fields, mappings and acceptance; ADR 0032 selects structured storage/contracts, field rights and history architecture. The nine contact codecs and base Contacts/Distribution-list provisioning are implemented locally. Relationship attributes and the shared date/instant/zoned temporal codec are implemented. Recurrence/calendar parties and complete exchange profiles remain open.
Decision
Section titled “Decision”PRD section 6.4 owns the required semantics and delivery boundaries. Use vCard 4.0 and iCalendar VEVENT/VTODO as the primary exchange references. Consider JSContact and JSCalendar as complementary JSON models. Select exact supported versions, applicable extensions and mappings in testable profiles before implementation; do not claim complete standards support from field-name similarity.
Keep domain meaning independent of presentation, storage and peers. Standard property mappings refer to supplied semantic identities, not editable labels or coincident custom field names. Repeated structured values and recurrence identities require explicit domain storage/contracts, not concatenated text or a JSON blob treated as an unvalidated custom field. Preserve the common metadata-driven application architecture, structural protection, configurable input aids, rights and journals. This decision does not select concrete tables or add new generic field kinds.
Later connectors use CardDAV/CalDAV with capability discovery and a declared profile. Separate transport metadata from business contents: remote collection/resource identity, exchange UID, remote version and synchronization baseline must not replace the record UUID or optimistic version. Define conflict/deletion rules and safe round trips before bidirectional synchronization. Unsupported peer behavior must be reported without silent data loss or changes to xObject’s model. Vendor-specific contact-group/category conventions are not domain rules. Nextcloud may be a test peer without becoming a dependency or specification authority; no product-specific adapter is introduced here.
The connector’s acting user remains subject to the same current application authorization, validation, atomic journaling and lifecycle rules as web/API/MCP. Scheduling participants, contact groups and external privacy/sharing properties are distinct from xObject security principals and grants. External data never implicitly authorizes fetching links, sending invitations or delivering notifications.
Consequences and delivery
Section titled “Consequences and delivery”Complete the five domain profiles and their acceptance mappings before building the affected fields and forms. Basic scalar timestamp storage remains unchanged until the domain contracts define richer temporal semantics. Retain V1’s exclusion of import/export, synchronization, calendar views, uploads and notification delivery. Approval/entitlement workflows, invitation scheduling and advanced task automation are not added merely because a standard can describe them.
Validate the defined supported subset with representative round-trip fixtures and explicit unsupported cases. Future peer tests must cover preservation, conflicts, deletions, identity and permissions. No such interoperability tests or runtime changes are delivered by this documentation decision.
Standards references
Section titled “Standards references”- Date of death extension — RFC 6474, selected for the optional Contact Date of death profile.
- vCard 4.0 — RFC 6350, including applicable extensions — RFC 9554.
- JSContact — RFC 9553, version 2.0 — RFC 9982 and vCard conversion — RFC 9555.
- iCalendar — RFC 5545 and task extensions — RFC 10051.
- JSCalendar — RFC 8984.
- CardDAV — RFC 6352 and CalDAV — RFC 4791.