xObject — Product Requirements Document

Status: Draft specification for version 1 Owner: ITextreme Updated: 2026-11-06

This document specifies the agreed product scope. Requirements below are product decisions, not claims of implementation or acceptance. Unresolved implementation choices are listed in section 10. Version 1 denotes the initial product scope, not a committed release date or an already assigned semantic version.

1. Purpose and scope

xObject is an open-source application for defining, managing and connecting structured data objects. Configurable modules provide domain models on a shared object platform. Version 1 supplies Contacts & Relations and Projects & Tasks, alongside user-defined object types. Their agreed object catalog is specified below; the domain-profile appendix proposes the concrete starting fields and relationships, with remaining implementation decisions identified separately. Documents & Communication and the other catalog modules are planned for later versions.

Version 1 includes workspaces, local user accounts, configurable data definitions, permissions, relationships, per-field change history, a recycle bin, tables, forms and record detail views with a Projects-owned Primary hierarchy tree and a dossier. All application capabilities must be available through both API and MCP from the outset.

Out of scope for version 1:

• Documents & Communication, Operations & Finance, IT Service Management, Configuration Management Database, Events & Registrations and Knowledge & Insights as supplied modules. Shared objects explicitly included in a V1 module remain in V1 even if another contributing module is deferred.
• File uploads, attachments and import/export features. API access to individual application operations is not an import/export feature.
• Desktop and mobile applications, SSO, offline operation and data synchronization, including CardDAV/CalDAV.
• Kanban and calendar views.
• General undo. Computed fields require a separate specification and are not included in this delivery baseline.

A paid cloud service is a later offering. The official initial installation target is self-hosting on Linux with Docker Compose.

1.1 Product vision and user need

xObject is intended to become a connected work environment for individuals and small to medium-sized teams. People and AI tools should be able to start from a work item, understand its permitted context and previous progress, act on it and resume later from another suitable client. The product should reduce the repeated manual reconstruction of information spread across records, notes, files, conversations and external applications.

The desired continuity covers four stages: finding the relevant starting context, working with complete and attributable information, saving results in the appropriate place, and resuming from the resulting decisions and open work. A useful outcome is that another authorized person or agent can understand what was done, why, which sources were used and what remains, without depending on the original chat or device.

The configurable object platform, supplied modules, Primary hierarchy, Dossier and Journal provide the foundation. The longer-term scope connects structured records with knowledge, source material, decisions, conversations and agent-assisted work. A record can be an entry point even when some related information is held by an external application. Existing source systems can remain authoritative; each information item must have an identifiable leading source rather than competing editable copies. Consolidating more contents within xObject is a long-term option, not an automatic migration requirement.

AI access is part of the product architecture. People and AI use the same application rules and current permissions. Relevant context must be discoverable and retrieved deliberately; connecting a client does not load the whole installation into its model context. The work record should remain useful when the model, client or executing device changes.

Self-hosting, open source, documented interfaces, portable data and manageable administration support user control over the system. Self-hosted storage and model processing are separate choices: sending contents to an external model is external processing and must follow explicit authorization and data-boundary rules.

1.2 Delivery boundaries

Version 1 delivers the object, domain, permission and API/MCP foundation specified in this document. Knowledge workflows, cross-source contextual retrieval, user-maintained agent profiles/skills, delegated jobs and automated execution are later targets in section 9.4, with no release assignment. Their acceptance criteria describe intended behavior, not implemented capabilities or additional V1 release gates. The supplied V1 skills in section 9.3 remain distinct from later user-maintained skills and execution management.

Later integrations must preserve the authority and access rules of their source systems. Replacing an existing application, migrating its contents or changing the leading source requires a separate supported transition. Product requirements are independent of any particular personal infrastructure, AI provider or runner implementation.

2. Terms and actors

Term	Meaning
Object type	A metadata definition such as Contact, Project or Task.
Record	One instance of an object type.
Record number / Datensatznummer	An optional configurable human-readable identifier, shown as Number / Nummer in the UI. Stored as record_number; distinct from the immutable technical UUID.
Field	An attribute defined for an object type.
Type	Optional standard field, added together with Status. A record classification that determines its permitted status values; distinct from object type.
Contact kind	Organization, Individual contact or Contact person; separate from Type and mutually exclusive per contact record.
Workspace	A boundary containing records, relationships, object types, groups, module activations and number sequences.
Module	An independently activated domain package supplying protected definitions and configurable input aids.
Primary association	The single direct hierarchical relationship used to derive a record’s context.
Dossier / Akte	A flat list of a record’s current accessible relationships.
Journal	The centrally stored change history, presented by record or as a system journal.
Access principals / Zugriffsberechtigte	Users and groups participating in a sensitive record, each with ownership rights. For activities, they identify the involved people/team and default notification audience.
Ownership rights / Besitzrechte	Record rights obtained through direct participation or membership of a participating group.
Foreign access / Fremdzugriff	Rights to another user’s/group’s records without participation, responsibility or automatic notification.
Source	The authoritative record or external resource from which information originates, including its identity and available version/freshness information.
Context package	A bounded selection of permitted contents, relationships, sources and work state prepared for a particular task. A later capability under section 9.4.
Agent profile	A versioned definition of identity, role and working style. It grants no permissions and is distinct from a user account or model.
Agent job	A concrete delegated work request with an authorizing user, intended result, scope and resumable work state.
Execution	One attempt to process an agent job, with its actual runner, versions, progress and result references. A job can have multiple attempts.
Runner	An authenticated execution environment capable of processing eligible jobs. It may use an AI model and tools within its authorized scope.
Automation	A recurring definition that can generate concrete jobs according to an authorized schedule and missed-run policy.

Role	Responsibility
Administrator	Installation-wide administration and full access to all workspaces and contents, including restricted fields and user-sensitive records.
Designer	Assigned per workspace. Configure user-defined types, fields, relationships and their input aids; configure the intended input aids of module fields while preserving protected definitions.
User	Assigned per workspace. View workspace settings read-only and use records according to effective permissions.
Agent	Act for an authenticated user with that user’s effective rights, never a separate privilege grant.

Administrators assign User or Designer roles through workspace membership. Users can view the entire Workspace settings section, while Designers and Administrators can change workspace configuration. Membership/role assignment remains Administrator-only. Designer status does not grant content permissions. Administrator scope is installation-wide.

Workspace groups have stable workspace-scoped identities. The target model supports user memberships and nested groups with explicit membership rights and cycle rejection. Administrators manage memberships, rights and activation; Designers can create empty groups and rename them, and Users can inspect permitted workspace configuration. A workspace member must not gain installation-wide privileges through a group. Removing workspace access revokes that user’s workspace memberships and grants atomically. Inactive accounts/groups and former workspace members do not contribute effective rights; names, references and journal identities are retained. Group lifecycle is described in ADR 0013; graded/nested memberships and section 4 inheritance are implemented locally under ADR 0027.

3. Object platform and modules

ID	Requirement	Acceptance criterion
R-001	A user can belong to multiple workspaces. Each workspace owns its records, relationships, types, groups, module activations and number sequences.	A non-admin user operating in workspace A cannot use identifiers to read or relate records from workspace B. An Administrator can access both without separate memberships.
R-002	Designers can define object types, fields and relationship types. PostgreSQL is authoritative for definitions and contents, with an individual data table per object type.	Creating a type and scalar field makes the field usable on its records. Invalid or failed definition changes do not leave a usable partial schema or unjournaled changes.
R-003	Version 1 supplies independently activatable Contacts & Relations and Projects & Tasks from installation-level templates. The remaining catalog modules are deferred.	Either V1 module can activate alone; activating both reuses shared definitions. Planned later modules cannot activate as delivered features. Activation checks conflicts/dependencies before applying changes atomically, without adopting custom definitions by name.
R-004	An object type can belong to multiple modules with one definition identity, record identity and set of stored values. Modules can contribute fields to the one common object form.	Editing a Contact in Contacts or Projects updates the same record and journal. Conflicting definition contributions/updates are rejected before changes. Deactivation retains definitions, values, relationships and history; shared objects remain usable through remaining active modules under the same rights. Unsatisfied dependencies block deactivation explicitly.
R-005	Module-supplied definitions are protected; Designers can add their own fields, configure intended input aids and customize the common object form within their declared layout boundary.	A protected module field cannot be structurally modified through UI, API or MCP. A Designer can change intended options and editable form groups, order and widths without copying the field or editing code. Contacts have a fixed supplied core for each Contact kind; Designers arrange additional fields and custom relationships around that boundary.
R-006	A record must satisfy required fields across its shared object type, including fields newly contributed by an enabled module.	Saving incomplete input reveals the missing fields for direct completion. If field permissions prevent completion, saving is refused with an actionable error without revealing restricted values.
R-007	User-defined fields containing data are deactivated rather than deleted in version 1. Field type changes require safe conversion of all existing values.	Deactivation retains stored values and allows reactivation after compatibility checks. Never-used definitions can be explicitly deleted after dependency checks; a historical metadata tombstone and journal remain. Used object types are deactivated rather than deleted. Type and Status fields share their lifecycle. A proposed type change containing even one unconvertible value is rejected without partial conversion or data loss. Protected module fields remain protected.

Personal Contacts have separate configurable Salutation and Academic-title choices. First name, Last name, Additional given names and Name suffix are plain-text inputs backed by the declared name representation. These personal fields are always visible in the fixed Name & organization core when applicable. Salutation does not form part of the formatted personal name; the academic title does.

Contact creation begins with Organization, Contact person or Individual contact selection before opening the form. The selected kind is fixed for creation and existing records; no in-form kind selector is offered. API/MCP reject kind changes after creation. A dedicated conversion workflow is later work. The derived Contact Keyword is shown as the record heading, without an editable/read-only Keyword form field.

Module catalog and shared forms

Stable module key	English name	German name	Delivery scope
contacts	Contacts & Relations	Kontakte & Beziehungen	V1: Contacts and Distribution lists; 11 additional object memberships are next-version scope.
projects	Projects & Tasks	Projekte & Aufgaben	V1: shared Contacts, Projects, Cases and Tasks; six additional memberships are later scope.
documents	Documents & Communication	Dokumente & Kommunikation	Later.
operations	Operations & Finance	Betrieb & Finanzen	Later.
itsm	IT Service Management	IT-Servicemanagement	Later.
cmdb	Configuration Management Database	Konfigurationsmanagement	Later.
events	Events & Registrations	Veranstaltungen & Anmeldungen	Later.
knowledge	Knowledge & Insights	Wissen & Erkenntnisse	Later.

The target catalog has 22 distinct shared object types, with five in V1, 11 additional Contacts objects deferred to the next version and six additional Projects objects deferred beyond V1: Contacts belongs to both V1 modules. Membership in a deferred module does not defer an object already included in a V1 module. Conversely, a later module’s other objects/functions are not included merely because it shares an object. Future modules may contribute fields to the common form of existing objects. The Delivery column below defines the release assignment; additional object catalogs require their own domain specification.

Contacts covers customers, suppliers, partners, service providers and other roles; a Contact can have multiple business roles. These roles are distinct from Contact kind and from application permissions. A module’s object catalog identifies the domain records to supply, not an unrestricted promise of accounting, messaging, scheduling or other specialized workflows.

The same object type and record can appear in multiple modules, with one shared identity and shared values. All contributing modules use one common configurable form; they do not receive copies of the object or record. Object-wide requiredness and rights apply. The standard form exposes all applicable active input fields; Contacts omit derived-name inputs and the immutable Contact-kind controller. Form groups, translated titles, scalar/relationship order, half/full widths, optional relationship visibility and initial multi-target table state are metadata under ADR 0025, separate from alphabetical definition lists and physical SQL column order.

Custom object forms begin with a freely editable starter proposal: General / Allgemein contains Keyword, other business fields and maximum-one custom relationship sides; Primary association / Hauptzuordnung has its own full-width section immediately before Classification; Classification / Einordnung contains Type, Status and Category; Relationships / Verknüpfungen contains multi-target relationship lists; Notes / Notizen comes last for an existing multiline notes field. Sections without corresponding elements are omitted; General remains the initial group. All group names, grouping and ordering are user choices; General, Business details and Relationships are not domain roles. New fields and relationships remain Unassigned until explicitly placed and stay available for entry. Removing a group unassigns its elements, including when removing the last group. Module templates normally supply editable initial proposals; Contacts use a fixed kind-specific core for names, Organization, contact details, addresses, classification, notes and module relationships. Designers configure additional fields, custom relationships and their groups. Contact core layout references are rejected by UI/API/MCP configuration; intended field input aids remain configurable. Protected module fields retain their structural protection independently of layout customization. Authored layouts retain unavailable field/relationship identities without changing their stored values.

The current local prototype has a dedicated Modules area with three database-backed entries: Contacts & Relations, Projects & Tasks and Documents & Communication. Projects & Tasks supplies base Contacts, Projects, Cases and Tasks with fixed Primary association. Contacts & Relations also activates, supplying structured Contacts and Distribution lists, derived names and regular membership/Identities edges. Contacts and Distribution lists meet their local V1 functional scope; Projects, Cases and Tasks have supplied lean profiles for the reduced V1 scope. Relationship attributes, shared object/field contributions, a common object form and additive template updates are implemented locally. The six additional Projects profiles remain later work. Container installation, backup/restore and current-target maintenance are implemented; actual released-predecessor migrations follow those predecessors. Shared Contacts reuse the same supplied object binding. Planned catalog entries must distinguish V1 targets from later modules; a specification is not activation support. Documents & Communication, email handling, uploads and attachments remain outside V1.

Planned ITSM ticket model

Status: idea for later evaluation, not a decided catalog change or an implemented feature. The ITSM module could reuse Cases (cases) with Type “Ticket”, suitable Status options and ticket-specific fields such as requester, affected service/device, impact, urgency and resolution. The one shared form would expose ticket-specific sections through the planned conditional field visibility, retaining common identities, values, permissions, activity assignment and journals.

Evaluate whether this shared model should replace the originally proposed Incidents (incidents) object. Problems, Changes and Maintenance activities require separate assessment; no consolidation of those objects is decided. The existing catalog remains unchanged until that evaluation is accepted. ITSM could supply shared Cases independently of Projects activation; Primary association and its tree would remain available only with the Projects module. Ticket fields or shared-object membership alone do not implement SLA calculations, escalations, email intake or notifications; those capabilities require their own specification.

3.1 Workspace codes and technical names

Each workspace has a freely editable display name and an installation-wide unique technical code chosen at creation. xObject proposes a code; the creator can edit it before saving. Codes begin with a lowercase ASCII letter and contain only lowercase ASCII letters and digits. The code sys is reserved for system tables. Workspace codes cannot be changed in version 1.

Object types and fields have immutable UUID identities, readable technical names and separately editable/translatable display labels. xObject proposes English snake_case technical names that the Designer can edit before creation. Technical names begin with a lowercase ASCII letter and contain only lowercase ASCII letters, digits and underscores. They are fixed after creation in version 1. Object technical names are unique within their workspace; field technical names are unique within their object type. Supplied module definitions use fixed technical names, reserved against custom object creation even while the module is disabled or planned. Activation must check for conflicting definitions before applying changes; a matching name alone does not identify a shared object type.

An object type’s data table is named <workspace_code>_<object_name>, for example itx_contacts, itx_projects or itx_vehicles for the workspace ITextreme with code itx. This uses table prefixes rather than a separate database schema for each workspace. Installation-wide system tables use the reserved sys_ prefix. Column names remain readable, for example birth_date and commercial_register.

Creation rejects reserved/conflicting names and names exceeding PostgreSQL identifier limits, including the complete generated table name. System-managed field names are reserved within object types. Display-label changes never rename tables or columns. UUIDs remain the references for definition identity, relationships and journal entries; authorization uses workspace/type identities and permissions rather than table-name prefixes. The backend applies the same naming validation through UI, API and MCP.

See ADR 0001 for the naming decision and its consequences. Production access isolation and migration execution, and references beyond the field types mapped in ADR 0007, still require technical design.

3.2 Shared fields

Field	Definition and default
id	Immutable UUIDv7, stored as PostgreSQL uuid. Relationships and journal entries use technical identities rather than record numbers.
created_at, created_by	System-managed creation metadata.
updated_at, updated_by	System-managed last-change metadata.
version	System-managed increasing version for detecting concurrent edits.
Keyword	Optional standard field providing a display name; when installed, required/optional configurable per object type, initially optional. German label: Stichwort; English label: Keyword. Free input except on Contacts.
Type	Optional standard field, added together with Status. Single choice; required/optional and default value configurable per object type.
Status	Optional standard field, added together with Type. Single choice from the selected Type’s permitted values; required/optional and initial status configurable. An empty Type has its own configured Status values.
Category	Optional standard field. Configurable options; required/optional, defaults and single/multiple/tree selection configurable per object type.
Record number	Optional configurable number sequence per object type and workspace.
Access principals	Protected virtual field for user-sensitive object types; group, order and half/full width are configurable in the Form designer. Security rules are specified in section 4.

ID	Requirement	Acceptance criterion
R-008	Shared fields and system metadata apply to both supplied and user-defined object types.	Standard field technical names and their German/English display names are reserved for standard fields, including when these fields are absent. New types receive system metadata. Keyword, the Type/Status pair and Category are optional standard field definitions that can be added later; absent fields are neither physical business columns nor editable record inputs. Existing definitions and contents are retained. Without Keyword, clients use the record ID for identification. Clients cannot replace system-managed IDs or bypass version checks. Two edits based on the same previous version cannot silently overwrite each other.
R-009	Designers configure all input aids: options, Type/Status mappings, categories, priorities, defaults, helper text and supported validation aids.	A changed configuration applies through UI, API and MCP without a code change. Existing option identities survive renaming and deactivation. Unused Types and Statuses may be deleted when no current or historical record references remain; retained Statuses must keep a valid Type. Deletions are journaled and deleted identities cannot be reused.
R-010	Type determines available Status values using a simple mapping, not an implied workflow engine.	A Type change retains a still-valid Status; otherwise the caller must supply a valid replacement or clear an optional Status. An empty Type only permits Status values explicitly configured for Without Type. Required/optional rules are independently configurable per object type and enforced through every access channel.
R-011	Number sequences support prefix, suffix, starting value, increment, padding and configurable restart rules.	Concurrent creations cannot obtain the same record number within the configured sequence. IDs do not change when number-format configuration changes. Monthly/yearly restart includes the period in the number, using the workspace time zone. Issued numbers and UUIDs remain unchanged; numbers are immutable, never reused and assigned only to new records while enabled. See ADR 0030.
R-012	Field configuration supports German/English labels, helper text, ordering, required/default values, applicable validation and uniqueness within type/workspace.	Invalid input is rejected by backend validation. Duplicate values in an enabled uniqueness rule cannot be accepted through concurrent writes.

Supported field types: Text, Multiline text with optional formatting, Integer, Decimal with configurable scale, Money with currency, Boolean, Date, Date/time with timezone handling, Single choice, Multiple choice, Selection tree, Email, Telephone with international formatting, URL, and User/Group references with single or multiple selection.

Scalar storage, collections and references must be mapped explicitly in the technical design; a multi-valued field must not be assumed to be one scalar column. Date-only values such as birthdays must retain their date meaning, while timestamps are displayed in the appropriate timezone.

Selection trees and multiple-choice dialogs

The general custom field kind Selection tree / Auswahlbaum (tree_choice) supports hierarchical multiple selection independently of Category. Category can also use single, multiple or tree selection. A node has one optional same-dictionary parent. Selecting a child includes all ancestors; deselecting a parent clears its descendants. Selecting a parent alone leaves its children unselected. Active children require active ancestors; cycles, cross-dictionary parents and invalid configurations are rejected.

Multiple/tree fields use a summary field with a selection button and a searchable list/tree dialog. Apply updates the form draft, then the ordinary Save persists it. Defaults follow the same semantics. Existing selections gain required ancestors atomically when a hierarchy changes, with record version increments and one journal entry per changed field. Preserve values on safe flat/tree conversion; reject single-choice conversion when it would discard selected values. Shared UI/API/MCP validation, permissions, history, requiredness and limits follow ADR 0037.

3.3 Languages and physical column order

Technical identifiers and stored business contents are language-independent. Translatable definition names are stored in a labels JSONB column on their definition table: sys_object_types and sys_fields, with Type/Status/Category option labels in the classification JSONB configuration described in ADR 0006. Relationship-type definitions follow the same language-map principle. For example, a field can store {"de":"Kennzeichen","en":"Registration"} while its technical column stays registration. Definition-label forms show one input with a language selector and per-language translation status; switching language preserves all draft translations until they are saved together. At least one supported-language label is required; German and English are the installed catalog initially. Each workspace independently configures its available interface languages, an active default, and nonempty definition-translation languages. Disabling a definition language retains stored translations and journals; the editor can display retained inactive translations read-only, and API/MCP reject changing or newly adding translations in an inactive language. Adding further languages must not require new per-language columns. Fixed application-interface translations belong in versioned repository resources; the web interface uses i18next under ADR 0004.

sys_users.language is an optional preference; null inherits the workspace’s sys_workspaces.default_language, which initially defaults to English. The explicit user preference applies only when that interface language is available in the current workspace; otherwise the workspace default applies without overwriting the preference. Label resolution tries this effective language, workspace default, English, German and finally a preserved label of unknown language. Definition-language availability governs editing rather than deleting or hiding saved labels. The login page offers the installed interface catalog before a workspace is selected. See ADR 0012. Record names, Keywords and free text are never automatically translated. Changes to labels and language preferences are application operations with the same permissions and journal rules through API and MCP. Historical journal values retain their original representation.

Timestamp display and input use the optional personal time zone, otherwise the workspace time zone. Store named IANA zones and UTC instants; date-only values remain unchanged. New workspaces propose the browser zone in the UI; API/MCP creation defaults to UTC; configured zones do not rewrite stored instants. Time-zone configuration shares application authorization, conflict and per-property atomic journal rules. DST gaps must be rejected and overlapping clock times require an explicit instant. See ADR 0014. Regional format, date format, 12/24-hour clock, numeric separators and first weekday follow workspace defaults with optional per-property personal overrides. These affect display and never convert stored values or currencies.

For newly created object data tables, physical columns start with id, created_at, created_by, updated_at, updated_by and version. Optional standard fields (Keyword, the Type/Status pair and Category) and user-defined fields are appended when created. They are listed only when installed in the object’s field metadata. Routine application operations and upgrades retain existing columns and do not rebuild data tables merely to reorder them or add missing optional fields. Physical column order is independent of form/table display order.

See ADR 0003 for the storage and migration decision. These rules elaborate R-001, R-002, R-008, R-012 and R-034–R-036; they do not introduce new requirement IDs.

Additional structured domain fields follow the staged architecture in ADR 0032; existing scalar Date/Date-time contracts stay unchanged. Structured fields use whole-field rights, typed component values and ordinary per-field journals. Relationship-attribute fields share definition identities and require both-endpoint rights as specified there; attribute-free linking retains its existing endpoint permissions.

Field explanations, creation defaults, scalar uniqueness and record-number rules follow ADR 0030. Defaults apply only on omission at creation, respect field creation rights and never backfill existing records. Unique values remain reserved in the recycle bin. Record numbers are immutable server-assigned values; disabling numbering retains the field and issued values.

3.4 Planned conditional field visibility

Status: agreed later extension; not implemented and not assigned to a release. Designers configure Display conditions / Anzeigebedingungen in field attributes. A field is always shown by default, or shown for selected Type and/or Status values. Conditions reference stable field/option UUIDs rather than labels; simple AND/OR combinations support cases such as Type “Complaint” AND Status “Closed”. Empty Type/Status values are explicit selectable cases. No script or general workflow engine is implied.

Display conditions are separate from semantic applicability under ADR 0023. Applicability describes whether a field value is valid for that record and currently rejects nonempty inapplicable values. Display conditions only control presentation and conditional requiredness:

• Hiding a field retains its existing value. Changing Type/Status does not clear, rewrite or fabricate a field value or a field-value journal event. Showing it again restores the retained value.
• A configured required field is required only when both semantically applicable and shown by its display condition. A Type/Status change that reveals an empty required field must complete it in the same save. Other value validation and semantic-applicability rules remain in force, including for retained hidden values.
• Field/object/record permissions remain independent. A display condition grants no access and provides no confidentiality boundary. Authorized API/MCP reads may still return a form-hidden value; hidden fields are not automatically forbidden API/MCP inputs. All channels share the condition configuration and backend enforcement of conditional requiredness, validation and permissions.
• Definition changes use the established optimistic versions, dependency protection, existing-record preflight and atomic definition journals. Renaming Type/Status options retains their references. The later implementation must define safe handling of removal/deactivation and reject ambiguous or cyclic dependencies.

Acceptance examples: hide a populated field by changing Type, save and reveal the unchanged value again; combine Type/Status conditions; handle explicit empty selections; require a newly revealed empty field; preserve rights restrictions through UI/API/MCP and record no synthetic value changes merely for hiding/showing. The current installation needs no speculative schema columns or compatibility paths; the metadata/editor extension is implemented when this feature is scheduled.

4. Permissions

4.1 Target model and delivery boundary

The model combines object/field permissions, ownership through Access principals and foreign access through user/group rules. This section is the product authority. ADR 0027 describes the local implementation, resolver, storage and current installation, extending the earlier ACL in ADR 0026. Calendar availability/time-only mutations and notification delivery remain separate future capabilities; reserved levels do not expose additional contents or implement a calendar. Reproducible validation and public evidence are described in development; they do not establish release or production acceptance.

The product deliberately keeps installation-wide Administrator content access. User/Designer are workspace configuration roles and confer no content rights. All other grants and inheritance are workspace-scoped. Agents use their authenticated user’s current effective rights through the same application layer as UI and API.

4.2 Object and field permissions

Administrators configure which object types each user/group can use and optional field exceptions. Object sensitivity is configured once per object type; activities are always sensitive, including Projects, Cases and Tasks. A non-sensitive object has no record-level participant restriction; every user authorized for that object can use its records within the applicable object/field limits. A sensitive object additionally evaluates ownership or foreign access for each record.

Object permissions use the content capability levels in section 4.3 as a ceiling; a separate Create capability controls whether new records may be created. Create alone exposes no existing record contents. Missing user Create settings inherit active group grants; an explicit user setting overrides that result. For non-sensitive records, the object ceiling directly determines available record actions. For sensitive records, the resolved record level additionally limits those actions. Rights on an existing record do not independently authorize creation of unrelated records. Field permissions are None, Read and Edit; Edit includes Read. Full access on a record does not override object or field restrictions. Duplication requires creation rights and a valid new record; it must not copy unreadable fields or create records with missing inaccessible required input. The web action opens an editable unsaved creation draft; preparation allocates no record identity, record number or journal event. Saving rechecks current Duplicate/Create rights and the source version before normal atomic creation. Unique/derived values, record numbers, ownership and relationships are not copied.

Active group grants combine by the highest applicable right. Explicit user object/field overrides remain available as administrative restrictions and replace the corresponding group result; an absent override inherits, while explicit None denies that capability. This is distinct from record ownership precedence below. If filtered grants are introduced, their field allowances stay tied to their own record scope: a broad object grant from one group must not extend a different group’s narrowly scoped field allowance. These rules apply independently of the ownership and foreign-access resolver. Optional per-record field exceptions can further restrict Read/Edit for a user or group without increasing administrative object/field ceilings or bypassing record access. Their direct-user/group precedence follows the same explicit-override rules; an absent record exception inherits. Record-level Full is required to manage these exceptions within the caller’s own authority. Protected security metadata must not become an alternate way to administer global/workspace grants.

4.3 Record rights and calendar visibility

The following content levels are cumulative. Each level includes the preceding content capabilities; None grants no access. None is an administrative object/field or foreign-access setting, not an active ownership entry. Available actions are the intersection of the content level, object ceiling, applicable field permissions and lifecycle/configuration rules. Full content access grants no configuration, account-security or protected-module privileges.

English / German	Meaning
Read / Lesen	Open an accessible record and read permitted fields.
Read and duplicate / Lesen und duplizieren	Additionally duplicate permitted contents, subject to target creation rights and validation.
Change times / Zeiten ändern	Additionally change the explicitly designated scheduling fields of calendar-capable records without editing unrelated content.
Edit / Bearbeiten	Additionally change permitted record contents.
Edit and delete / Bearbeiten und löschen	Additionally move the record to the recycle bin.
Full access / Vollzugriff	Additionally restore, permanently delete with confirmation and manage Access principals within the caller’s effective authority.

Calendar availability visibility / Kalenderbelegung sehen is an additional foreign-access capability below Read. It exposes only an authorized busy interval (start/end), not the record, Keyword, participants or other contents. It does not permit opening the record or changing times. Keep availability projection separate from ordinary record reads and from the higher Change times level. It has no effect on objects without designated scheduling fields. Calendar views, availability projection and time-only editing remain later delivery with the calendar feature, outside version 1; generic date fields do not automatically become scheduling fields.

4.4 Access principals, ownership and activity involvement

The protected field remains named Zugriffsberechtigte / Access principals, technically access_principals. Activities are always user-sensitive; this includes Projects, Cases and Tasks in V1. Module provisioning enables sensitivity and supplies the protected Access principals field. Administrators cannot disable activity sensitivity through UI, API or MCP. Future activity profiles follow the same invariant. Each entry references a workspace user or group by stable identity and carries an ownership level. On non-activity records the list denotes ownership/access participation, not a work assignment. On activities such as Tasks and future Phone calls, the listed users/groups are the people/team involved in performing the activity and the default notification audience. A participating group represents team work; it does not assert that every member must separately complete the activity. Per-member completion tracking is a separate, unspecified feature. Read-only participation is possible.

New sensitive records initially include their creator with Full ownership, bounded by object/field rights. A participating group’s ownership is bounded by each member’s membership level, including nested membership limits. A nested membership path is limited by its lowest membership level and the group entry’s ownership level. Several group-derived ownership paths combine by their highest permitted result. Inactive or removed intermediate memberships contribute no path. A direct user ownership entry takes precedence over group-derived ownership, even if lower. If ownership exists, it takes precedence over foreign access, even when foreign access would be higher. An inactive/unavailable principal cannot be newly selected; retained references remain identifiable without conferring rights.

Only eligible users/groups with access to the object can be newly selected. The selector uses authorized workspace identities and object eligibility; foreign access to someone’s records is not an additional prerequisite for selecting that eligible person. Selecting a group keeps one dynamic group entry; expanding it deliberately creates individual entries, whose later participation no longer follows membership changes. These two actions must be clearly distinguished. Full access is required to edit the list. A caller cannot delegate a level or capability beyond their own effective authority or bypass administrative object/field ceilings. Changing Access principals changes involvement and rights together; it must explain loss of the caller’s own access before saving. Removing the creator delegates participation to the remaining principals. The creator retains only rights obtained through the normal current resolver, including explicitly configured foreign access. There is no hidden perpetual creator grant after the creator is removed. This also applies after repeated delegation; historical creator metadata never supplies a grant.

An empty list continues to mean public within the authenticated workspace, subject to object/field rights. The UI makes this explicit as All (workspace) / Alle (Arbeitsbereich), not anonymous Internet access. The current policy represents workspace-public mode and its ownership level explicitly, bounded by object/field ceilings; it never infers a grant from missing policy metadata. Clearing the last entry explicitly returns to this workspace-public mode and requires the normal Full/delegation checks and a visibility warning. An explicit public level can later be lowered within the caller’s authority. In public mode, direct user ownership takes precedence, followed by applicable participating-group ownership and finally the public fallback; foreign access does not override a lower ownership result. A nonempty list whose users/groups become inactive or unavailable never turns public automatically. Public visibility alone does not assign work to every member or subscribe the whole workspace to activity notifications.

Access principals are the single source for activity participation and work assignment, including Task assignees. The supplied Task has no separate Assigned to field or assignment storage. Responsible person denotes coordinating responsibility and grants no content rights. Ownership changes use the shared security writer and are journaled atomically; foreign access grants rights without adding activity participants or assigning work.

4.5 Foreign access and inheritance

Administrators configure requester → owner rules between workspace users/groups: for example, Hans may Edit Clara’s records, or Sales may Edit Administration’s records. Each rule has a default level and optional per-object overrides; absent access grants nothing. A missing per-object override inherits the rule default, whereas explicit None disables that rule for the object. Defaults do not span workspace boundaries. The default per-record maximum is Full, which caps an existing foreign grant but never creates one. The inverse “Access from others” view edits the same rule, not a second competing permission. Foreign readers/editors do not become participants, assigned workers or default notification recipients. For example, Hans → Clara Edit allows Hans to edit Clara’s Task while Clara remains the participant/work recipient; Sales → Administration similarly permits Sales to work on Administration-owned contents without assigning Administration’s work to Sales.

Group inheritance applies on both sides. A requester inherits its groups’ foreign access, and a rule targeting an owner group covers records directly assigned to its members as well as records assigned to that group. Thus Management → Sales applies to a record directly assigned to Hans when Hans is a Sales member, even though neither Sales nor Management is in the record’s Access principals. Martin inherits the rule as a Management member. Nested groups are supported; cyclic group membership is rejected.

Transitive foreign-access paths must also be represented explicitly in the resolver design rather than accidentally lost: if E has foreign access to A and A to D, E can have inherited access to D’s records through that authorized path. For a given object, each path takes the least permissive of its applicable foreign grants and graded memberships; only actual ownership entries can terminate a path. A direct ownership restriction on an intermediate user cannot be bypassed by pretending that user has a higher foreign right to that record. Record privacy/maximum and the requesting user’s object/field ceilings are applied to the resulting action. Inheritance cannot turn an intermediate user’s mere object permission or historical creator identity into ownership. Confidential access cannot be forwarded along a path that lacks the separately required confidential capability. These are explicit xObject evaluation rules; the implementation ADR must specify the finite graph resolution and verify the precedence cases before delivery. Multiple eligible foreign-access paths combine by their highest permitted result. Cycles must terminate and must not create an initial grant or escalate rights. Group membership alone must not silently grant access to coworkers’ individually assigned records: mutual access is an explicit group-to-itself foreign-access rule. The UI must explain the winning path and relevant limits.

Administrative inheritance controls must distinguish direct rules from group-derived rules. If group-derived foreign access is disabled for a user, that user’s direct foreign rules still apply; inherited grants must not survive through another equivalent group path. Membership, activation and rights changes take effect on subsequent operations in an existing session, without requiring sign-out.

4.6 Per-record foreign-access limits

Each sensitive record has a maximum foreign level plus a privacy mode (Normal, Personal or Confidential). Normal is the creation default; its maximum defaults to Full without granting anyone access. The limit applies to every direct and inherited foreign-access path, never to ownership:

• A normal maximum level caps the actions available through foreign access.
• Personal / Persönlich excludes foreign access; only ownership and the explicit installation Administrator exception remain.
• Confidential / Vertraulich requires a separately granted confidential-access capability in addition to the ordinary foreign level and object/field rights. It is not an extra level granting Full access.

Public mode cannot simultaneously be Personal or Confidential: the UI and backend reject this combination and require explicit non-public owners before such privacy can be saved. Clearing the last owner of a Personal/Confidential record must ask for an explicit change to public Normal mode rather than silently exposing it. Changing the maximum or confidentiality is a permission change subject to the same Full-access/delegation limits and journal rules. The future calendar has an independent, explicitly configured workspace privacy policy for busy-time disclosure on Personal/Confidential records. Until configured, no such projection is exposed. When permitted, it reveals only a generic busy interval, never titles, participants or contents. Ordinary record endpoints still deny access; availability-only users do not contribute ordinary readable-record counts or journal results. xObject’s Administrator exception is intentional and differs from ordinary ownership and foreign access.

4.7 Notifications, defaults and administration

Activity notification rules normally address explicitly participating users and eligible active members of participating groups, after resolving their current access (at least Read). A participant list defines recipients; it does not by itself cause an email for every edit. Event selection, own-change handling and delivery preferences belong to the later notification design. Merely obtaining foreign access does not subscribe a user. An explicit later subscription/rule may notify a foreign-access user who has the required current rights; this never adds ownership. Member delivery is the target default for participating groups and deduplicates users reached through several groups or direct participation. A configured shared group destination is an optional later delivery mode that requires an explicitly authorized content policy; it cannot be treated as a user with permissions or bypass members’ field restrictions. Delivery failures do not roll back a successfully saved business record; reliable queuing/retry requires the later notification design. Public records do not broadcast automatically. Scheduled jobs re-evaluate current rights before exposing contents; payloads must not include restricted fields. Mail delivery, alarms and notification subscriptions remain later work, not a version-1 delivery claim.

A STANDARD user/group template is a creation template, not a universal group or an automatic grant to all users. A user’s default group, if configured for creation defaults, is a separate concept; it must not silently add owners or widen access on existing records. Concrete template/default-group behavior must be designed before enabling it.

Only Administrators configure security policy, foreign grants, graded/nested memberships and sensitivity. A user-facing ability to change general foreign access on one’s own records is not enabled implicitly; it requires a separate explicit Administrator delegation setting and remains bounded by administrative ceilings. Workspace/instance security-administration authorization cannot be obtained merely through a foreign Full grant on a business record. Designers continue to configure object definitions, fields and input aids. Record-level Full holders manage their record’s Access principals and foreign-access limits within the above ceilings. Settings must expose effective rights with their source, direct/inherited status and limiting rule, so “may edit” is distinguishable from “is participating”. Previews must use the same resolver as actual authorization.

Permission, membership, public/private, participant and foreign-limit changes are versioned, atomic with one journal entry per changed property and a common change ID. Current rights govern historical projections; immutable stored history is not rewritten when ownership changes. Restricted contents must not leak through search, counts, filters, sorting, Dashboard, relationship candidates, Dossier, Primary tree/context, journals, notification payloads or error messages. Primary/General/custom relationships never confer content rights.

4.8 Migration and verification

The unreleased application has one current installation baseline under ADR 0028. Development databases are recreated from that baseline, with no older-schema adoption or compatibility behavior. Each sensitive record has exactly one security policy; its virtual Access principals field is derived from the graded owner entries. Enabling sensitivity initializes policies for currently unrestricted records as workspace-public; disabling sensitivity on non-activity objects requires explicit Administrator confirmation and retains their policies for re-enabling. Activity sensitivity cannot be disabled. Backup/restore and fail-closed maintenance are specified in ADR 0035; migrations from actual released predecessors are added when those predecessors exist.

ID	Requirement	Acceptance criterion
R-013	Object and field permissions bound all non-admin content access; non-sensitive records have no participant restriction.	A user without object access remains excluded even with a foreign rule; field restrictions apply to every content level.
R-014	Sensitive records resolve ownership from graded user/group Access principals or foreign access, with the precedence and caps above.	Clara participates and can act at her ownership level. Hans with foreign Edit can edit without appearing as a participant or becoming a default notification recipient. A direct participant Read overrides group Full and foreign Edit.
R-015	Public means authenticated workspace access bounded by object/field policy; new sensitive records initially include the creator.	Clearing the list preserves public semantics, never anonymous/cross-workspace access or mass assignment/notification. Removing the creator leaves no hidden creator grant.
R-016	Effective rights account for user overrides, graded/nested memberships, foreign inheritance and per-record limits.	Martin in Management can Edit a record assigned directly to Hans in Sales through Management → Sales Edit. A group self-rule explicitly enables coworker access. Read caps, Personal, disabled inheritance, inactive principals and cycles cannot be bypassed.
R-017	Administrators have full installation-wide content access regardless of membership, object/field rights, ownership, foreign access and record privacy.	UI/API/MCP apply the Administrator exception while retaining validation, immutable journals, protected definitions and permanent-deletion confirmation.
R-018	Linking and ordinary reference fields grant no rights; shared enforcement covers all projections and channels.	A parent viewer or user merely referenced in Responsible receives no implicit access. Activity assignment uses Access principals and their ownership rights. Explicit participant changes are journaled. Search, history and future notifications cannot expose restricted contents.

Additional acceptance cases for R-013–R-018:

1. A participating group with Full gives a Full member Full ownership and a Read member Read ownership, bounded by object/field policy. Changing membership rights applies without a new login.
2. Sales → Administration grants access to Administration members’ directly owned records without adding Sales participants. Multiple independent paths resolve consistently; nested membership cycles are rejected and foreign cycles terminate.
3. A Read foreign maximum caps every inherited path. Personal excludes foreign access; Confidential requires the extra capability. Ownership remains decisive and installation Administrators remain unrestricted in content access.
4. Duplicate, time-only editing, recycling, restore, permanent deletion and principal changes each require their exact capability. A duplicate cannot copy a hidden value. Availability-only access cannot open a record or infer its Keyword through other projections; calendar cases are later acceptance.
5. Notification rules distinguish participating Clara/team from foreign-access Hans/Martin; an explicitly enabled foreign subscriber is separately authorized. Public visibility alone never generates a broadcast; notification cases are later acceptance.
6. Future supported release upgrades preserve effective access and history under R-046, with no automatically created foreign grants; unreleased development instances are recreated under ADR 0028. Concurrent permission/record changes cannot publish a partial decision or unjournaled mutation.
7. A record owned only by a now-inactive group stays restricted. Public Full is bounded by object rights; a direct participant Read restricts that person even in public mode. Public plus Personal/Confidential is rejected without an explicit mode/owner change.
8. Object Create with permitted initial field input can create a valid record without ownership/foreign access to other existing records; it cannot list those unrelated records. Ownership/foreign Full without object Create cannot duplicate or create unrelated records. Sensitivity disable/re-enable retains stored principals/history and requires an explicit widening decision.
9. A dynamic participating group follows current membership; deliberate expansion to individual principals retains only those individual entries. Merely selecting or inheriting foreign access never adds an owner or work recipient.
10. A Read edge limits a multi-hop foreign path to Read. A higher independent path can win only if it satisfies all privacy and object/field limits. Direct participant Read remains decisive over foreign Full, including intermediate-user paths; source explanations and backend decisions agree.
11. A record-level field exception can reduce an otherwise editable field to Read/None for a principal. Removing that exception restores inheritance; no record exception can reveal an administratively hidden field or an inaccessible record. Exception changes are versioned and journaled with the record.

4.9 Scope and implementation handoff

This is xObject’s independent product model. The following boundaries are intentional and must remain visible in implementation work:

Concern	xObject decision
Administrator	Installation-wide content access, including Personal/Confidential, with validation and immutable journaling still enforced.
Administrative restrictions	Explicit user object/field ceilings can restrict group-derived permissions; filtered field allowances cannot escape their record scope.
Coworker access	Membership alone grants no foreign access to coworkers; configure a group self-rule explicitly.
Delegation	No retained creator privilege; rights after delegation follow current ownership and foreign rules.
Public records	Workspace-only public fallback; no implied work assignment or broadcast.
Security administration	Administrator-only by default, separate from Full on business records.
Identity representation	Stable user/group UUID references, not display-name matching or comma-separated names.
Calendar and notifications	Rights/recipient concepts are specified; actual views, privacy projection, delivery and subscription behavior remain later scope.
Other features	Resources as participants, external invitees, synchronization, print/export controls and per-member task completion are not added to version 1 by this permission specification. Future features must reuse the shared authorization layer.

ADR 0027 defines the implemented stored grants/membership/record-privacy representation and capability mapping, finite path evaluation and revocation/concurrency behavior, and the current fresh-installation boundary in ADR 0028. Section 4.8 is the minimum behavioral test matrix. Settings must locate object/field grants and foreign access under workspace users/groups and record ownership/privacy in record details, with a clear explanation of effective access. STANDARD creation templates and optional default groups remain separate future configuration; they are not prerequisites for implementing this access model.

5. Relationships and primary association

General relationship types support 1:1, 1:n, n:1 and n:m. Each side’s maximum cardinality controls display: at most one partner uses a selection field; multiple possible partners use a list. Minimum cardinality determines whether a relationship is required.

The General relationship belongs to the application core. The Contacts module supplies the Contact-person / Organization relationship; the Projects module supplies Primary association for all object types while enabled. These are distinct relationships: a Contact person’s Organization does not count as its Primary association. Projects activation and its fixed base-object installation are implemented under ADR 0021. Contacts activation already provisions Contacts, Distribution lists and their supplied relationships. Shared object/field contributions, common forms, retained activation/deactivation and additive template updates are implemented; remaining domain profiles and released upgrade tooling are separate; a matching technical name alone must never convert a custom definition into a module-owned one.

The two protected system types are: Primary association (directed, at most one direct parent) and General relationship (undirected, optional/unlimited). Custom types each connect exactly one left and one right object type; they may be directed or undirected, with names for both sides and per-side minimum/maximum cardinality. Used object pairs and direction remain fixed for consistent historical reporting. For symmetric undirected endpoints, both sides use identical labels and cardinalities. ADR 0018 specifies definitions; ADR 0019 adds record connections, explicit activation/preflight, cardinality enforcement and selection/list controls. ADR 0020 adds the tree and derived ancestor display; object-level required associations/ancestor levels are implemented under ADR 0024.

Object settings expose a workspace-local primaryRequirements configuration: associationRequired requires at least one direct parent; requiredLevels independently selects Contact, Project and/or Case from the levels permitted above that object. An inherited level satisfies the same requirement as a direct one. Selected levels imply a parent even if associationRequired is false. Defaults are false/empty. Administrators and Designers configure these rules through the same versioned configure_object_settings operation as labels/numbering; each changed property has its own definition-journal entry in one change group. Stricter rules preflight all retained records, including recycled records, under the shared model lock. Every relationship write validates the final retained graph, including descendants affected by ancestor changes; ordinary create/update, linked creation, duplication and restoration use the same rules. Violations roll back contents, edges, versions and journals together. Requiredness uses structural UUID paths regardless of the actor’s read access and never grants access. Recycling retains the parent/edges and still satisfies structural requiredness; hidden/recycled context stays unavailable in the authorized UI projection. Required Primary elements remain visible in the effective form/designer. A refused configuration/write reports the required-context conflict without disclosing hidden records.

Saved, editable records offer two object-first header dropdowns: Link with… selects existing records; New linked record opens the normal creation form with a preselected source relationship. General-only objects are direct items; objects with additional eligible relationships have a submenu using the existing General label and side labels. Record and link creation is atomic; cancelling creates neither. Rights, endpoint conditions, cardinalities and source/definition versions apply equally through UI, API and MCP. See ADR 0019.

ID	Requirement	Acceptance criterion
R-019	Relationship cardinalities are enforced on every mutation.	A second partner cannot be added on a side whose maximum is one, including through concurrent writes. For Organization-to-Projects, the Organization displays a project list and the Project a single Organization selector.
R-020	A record has at most one direct Primary association. The contextual chain is Contact → Project → Case.	A record directly assigned to a Case derives that Case’s Project and Contact where present. Moving the Case updates derived context without independently editing child records.
R-021	Primary association is stored as a relationship and displayed as a selector. Other relationships can coexist.	Changing the selector changes the underlying relationship. Extra general relationships do not create a second Primary association.
R-022	Association requiredness and required ancestor levels are configurable per object type/workspace within the fixed Contact → Project → Case roles. All start optional; configuration cannot substitute other object types for those roles.	A standalone Task and an internal Project without Contact are accepted with default settings. Enabling a full-chain rule first validates all retained records, including the recycle bin. New/updated/duplicated/linked/restored records and ancestor edits preserve all required levels atomically.
R-023	Stricter relationship rules require a preflight over existing affected records and cannot activate while any violate the new rule.	Tightening n:m to a maximum of one or requiring a Project reports a conflict without exposing inaccessible records and leaves the old rule active until violations are resolved. Activation must also account for concurrent changes.

The Projects & Tasks module supplies a fixed Contact → Project → Case chain, bound to the supplied object UUIDs. Users cannot assign different object types to these levels. Workspace Modules controls activation; there is no independent level editor or write operation. Activation creates protected base Contacts, Projects, Cases and Tasks atomically and rejects matching custom technical names without adopting them. Contact is a root, a Project can have a Contact, a Case can have a Contact or Project, and other records can have one of these levels as a direct parent. Missing record levels are allowed unless the source object requires them. Details shows single-value fields with Choose/Change, Open and Clear controls for every available level, disabling unavailable actions. Changing a level clears later selections; clearing Case falls back to Project or Contact, clearing Project retains Contact, and clearing Contact removes the complete selection. Only this record’s deepest selected direct relationship is persisted; ancestor records and their own associations remain intact. A level-specific picker filters Projects by the selected Contact and Cases by the selected Project, or by Contact when Project is absent. Server filtering follows readable active Primary paths before counts/pagination; hidden intermediate records do not become a filtering oracle. Primary association is unavailable with Projects & Tasks disabled; existing Primary links and object-level requiredness must be cleared before disabling it. Definitions, records and UUID bindings remain retained. See ADR 0024. The record-header Link with… action selects General or an eligible specific relationship as described above. General links and subordinate Primary records are listed in the Dossier without duplicate Details tables. Details shows a labeled single-value field on custom sides with a maximum of one and a table on multi-target sides; selection remains governed by cardinality.

Custom relationships may restrict either endpoint through an active, unconditional single-choice field and allowed option IDs. Symmetric relationships use the same condition on both sides. Candidate filtering happens before counts/pagination; record discriminator changes cannot leave incompatible existing relationships behind. Controller fields and referenced options remain protected from incompatible changes. These are generic definition rules, not special behavior inferred from Contact names.

Tasks and other eligible records can attach directly to a Contact, Project or Case, or remain standalone under the configured rules. Appointments and Vacations are later Projects scope; supplied Documents and Phone calls belong to the later Documents & Communication module. Custom types can use the same relationship engine independently of those future modules.

6. Supplied domain models

The target catalog comprises 22 distinct object types: five in V1, 11 additional Contacts & Relations objects deferred to the next version and six additional Projects objects deferred beyond V1. Contacts & Relations supplies Contacts and Distribution lists in V1; Projects & Tasks retains its agreed V1 scope. German/English names and technical names are specified here once; module membership reuses that identity. Common platform fields follow section 3.2 and each installed template must define its initial standard-field selection. Structural module definitions remain protected; configurable input aids, field additions and layouts follow R-005/R-006.

German name	English name	Technical name	Modules	Delivery	Domain purpose
Kontakte	Contacts	contacts	Contacts; Projects	V1	Organizations, individuals and Contact persons; section 6.1.
Belege	Vouchers	vouchers	Contacts	Next version	Structured business voucher records and their associations.
Fremdleistungen	External services	external_services	Contacts	Next version	Externally provided services and their business context.
Kampagnen	Campaigns	campaigns	Contacts	Next version	Planned contact-related campaigns and their associations.
Kontaktberichte	Contact reports	contact_reports	Contacts	Next version	Documented interactions with Contacts.
Positionen	Line items	line_items	Contacts	Next version	Individual business items associated with their parent records/products.
Produkte	Products	products	Contacts	Next version	Goods or service offerings in business relationships.
Produkteinsätze	Product usages	product_usages	Contacts	Next version	Instances of a product being used in a business context.
Produktgruppen	Product groups	product_groups	Contacts	Next version	Organizing Products into configurable groups.
Spesen	Expenses	expenses	Contacts	Next version	Business expense records and their associations.
Verkaufschancen	Opportunities	opportunities	Contacts	Next version	Potential business opportunities with Contacts.
Verteiler	Distribution lists	distribution_lists	Contacts	V1	Explicitly maintained selections of Contacts.
Verträge	Contracts	contracts	Contacts	Next version	Contract metadata and associated business records.
Aufgaben	Tasks	tasks	Projects	V1	Actionable work; section 6.2.
Projekte	Projects	projects	Projects	V1	Larger undertakings; section 6.2.
Ressourcenpläne	Resource plans	resource_plans	Projects	Later	Planned allocation of resources to work.
Risiken	Risks	risks	Projects	Later	Risks and their treatment in a work context.
Termine	Appointments	appointments	Projects	Later	Scheduled activities and associated records.
Urlaube	Vacations	vacations	Projects	Later	Planned leave and its work context.
Vorgänge	Cases	cases	Projects	V1	Coherent matters; section 6.2.
Zeiterfassungen	Time entries	time_entries	Projects	Later	Recorded time associated with work.
Ziele	Goals	goals	Projects	Later	Objectives and their associated work.

This catalog does not mean that these supplied definitions are implemented. The four initially elaborated profiles are Contacts, Projects, Cases and Tasks. Their confirmed fields/rules are in sections 6.1/6.2. The domain-profile appendix now provides proposed minimum fields, supplied relationships and acceptance cases for the target catalog under section 6.3; the Delivery column determines the release scope, distinguishing prior decisions from new starter proposals and unresolved technical contracts. Catalog membership alone does not establish approved specialist workflows or module delivery. Organization, Individual contact and Contact person remain kinds of the one Contacts object, not three object types.

6.1 Contacts

Contacts share one contact basis. Contact kind is separate from Type and is exactly one of Organization, Individual contact or Contact person.

Accepted additional profile scope comprises Job title (TITLE), Function (ROLE), Department/organizational units (ORG), Nickname, communication languages, messenger addresses, Contact time zone, Wedding anniversary and Date of death. Photo/Logo are prepared only, with uploads still deferred. Nickname, communication languages, messenger addresses, named contact time zone, Wedding anniversary and Date of death are implemented locally; Photo/Logo has disabled presentation preparation only. Position/Function/Department are implemented as Contact fields; media storage remains pending; the domain-profile appendix owns their detailed meaning and boundaries. Wedding anniversary and Date of death are optional for Individual contacts and Contact persons, support an unknown year, and remain separate from Date of birth. Date of death appears with Date of birth in Further details; an empty value makes no statement about whether the person is alive.

The local prototype implements generic field applicability by stable single-choice field/option identities and explicitly configures the fictional Contact fixture under ADR 0023. Incompatible discriminator changes are rejected until nonempty values are explicitly cleared. Module activation now supplies protected Contacts and Distribution lists, conditional name requirements, derived Keyword/formatted name and permission-aware Organization-name projection. Contact kind is selected before creation and normal writes cannot change it. Job title, Function and Department are direct Contact fields for Contact persons and Individual contacts, always shown for those kinds in Professional details beneath Photo. Contacts and Distribution lists have passed the local CRM acceptance described in the development guide, including API/MCP, rights, journal and lifecycle scenarios. Full-product V1 release acceptance remains separate.

Field	Organization	Individual contact	Contact person
Organization/company name	Required; includes associations and other organization forms.	Available. If empty, Last name is required.	Derived from the Organization relationship.
First name, Last name	Not applicable.	Available; Last name required when company name is empty.	Available; Last name required.
Email, Telephone	Available.	Available.	Available.
Street, House number, Postal code, City, Country	Available.	Available.	Available.
Commercial register	Available.	Available.	Not applicable.
Date of birth	Not applicable.	Available.	Available.

Individual contacts may represent people or sole businesses and can use all available Contact fields. A Contact person record can belong to at most one Organization; an Organization can have multiple Contact persons. There is no secondary Organization membership for the same Contact person record. Minimum cardinality remains configurable independently of this maximum. The regular endpoint-condition engine limits the Organization side to Organizations and the Contact-person side to Contact persons; candidate queries and final-state writes use the same rules.

Identities is a relationship list on a Contact person or Individual contact, linking other Contact person and/or Individual contact records representing the same real-world person. It is not a separate object type, login account or technical record-identity registry. For example, a Contact person at Organization A can list a separate Contact person at Organization B and an Individual contact for private details. The linked records retain their own fields, Organization relationship, rights and journals; linking does not merge values or grant access to other records.

Domain roles are stored on each Contact person record, which belongs to at most one Organization: the Contact person at Organization A may be a board member, while another Contact person record linked through Identities is a regular member at Organization B. These roles are distinct from application roles. The local prototype implements this direct, symmetric AP/Individual-contact list through regular conditional relationship definitions. It does not create a separate Identity object or infer transitive identity groups. Base Contacts/Distribution-list provisioning and protected definition ownership are implemented locally. Generic relationship attributes and shared module contributions and a common object form are implemented locally.

ID	Requirement	Acceptance criterion
R-024	Contact kind is selected before creation, immutable in normal updates, controls applicable fields and is mutually exclusive per record.	Organization cannot persist a Date of birth, and Contact person cannot persist a Commercial register value, through UI/API/MCP. Applicable fields remain subject to field permissions.
R-025	Contact Keyword is derived from source fields.	Organization: company name. Individual contact: company name if populated, otherwise Last name, First name. Contact person: Last name, First name (Organization name). Updating source data updates the derived Keyword.
R-026	A Contact person belongs to at most one Organization through the Contacts relationship. An Identities relationship list on each Contact person/Individual contact links related Contact records without introducing another object type.	UI/API/MCP reject a second Organization membership for the same Contact person. Changing its Organization changes the derived Keyword suffix. An Organization can have multiple Contact persons. The Identities list can link separate Contact persons at Organizations A and B and an Individual contact, subject to record rights.
R-027	Job title, Department and configurable multiple Function roles are direct fields on Contact persons and Individual contacts.	Professional details is always displayed for these two kinds, including an Individual contact without a company name. Organizations do not accept these fields. Separate Contact records linked through Identities retain independent values. Changing/removing Organization preserves these fields; edits use the Contact’s field rights and record Journal.

The Organization membership is a Contacts relationship designation, not a requirement to enable the generic full Primary association chain. Repeated communication/address data and partial birthdays must follow section 6.4; typed JSONB storage and the fixed kind-specific Contact forms are implemented under ADR 0032. Position/Function/Department are direct fields on Contact persons and Individual contacts. Organization membership has no supplied attribute fields. Generic relationship fields remain independently available.

Planned Contact-kind conversion workflows

Status: agreed later extension, outside the accepted V1 CRM scope; no release number or implementation is assigned. Normal Contact updates keep their kind immutable. Dedicated guided actions from the record actions menu will handle these conversions:

Action	Result
Form organization → new Organization / Firmenbildung → neue Organisation	Create a new Organization and convert the existing Individual contact into its Contact person. The existing Contact retains its identity; the new Organization receives its own identity.
Form organization → existing Organization / Firmenbildung → bestehende Organisation	Convert the Individual contact into a Contact person of the selected existing Organization.
Continue as Individual contact / Als Einzelkontakt weiterführen	Convert the Contact person into an Individual contact and remove its Organization membership.
Reverse organization formation / Firmenbildung aufheben	Convert all Contact persons belonging to the selected Organization into Individual contacts and remove their Organization memberships.

The last action is a new business operation against current records, not a restoration of earlier snapshots: other Contact persons or changes may have been added since formation. The Organization remains available and can be deactivated separately. Ordinary Organization replacement/removal without changing Contact kind remains a distinct existing operation.

Common rules for the guided workflows:

• Preserve existing Contact UUIDs, record numbers, history, security policies and compatible relationships, including Identities and Distribution-list membership. The operation itself grants no additional content access.
• Show a preview of the resulting records, Contact kinds, Organization assignments and the proposed mapping of company/personal fields before confirmation. Existing Organization values are overwritten only after an explicit decision. No incompatible value or relationship is silently discarded.
• Collect missing target-kind required values before conversion, including a personal Last name when an Individual contact previously represented only a sole business. Recalculate derived names using the existing rules and the resulting Organization assignment.
• Check current authorization, record/definition versions, requiredness, field applicability, uniqueness, relationship cardinalities and endpoint conditions against the complete resulting state. Conflicts must be resolved before execution; hidden values remain protected.
• Save the complete confirmed operation atomically, including all affected Contact persons and the new Organization where applicable. Journal every field and relationship change under one shared change ID, retaining before/after Contact kinds and record identities. Failure leaves all affected records unchanged.

Before implementation, specify exact field mappings and the required operation/field permissions, handling of incompatible custom fields/relationships and concurrent membership changes, plus acceptance cases for restricted users and the multi-record action. These details do not authorize automatic copying or overwriting of Organization data. UI, API and MCP must use the same dedicated workflow and transaction rules.

6.2 Projects

The common fields apply to every supplied type. Additional fields are:

Object type	Meaning	Additional fields
Project	A larger undertaking.	Description, Responsible person (User/Group), Start date, Target date, Notes.
Case / Vorgang	A coherent matter such as an inquiry or complaint.	Description, Responsible person (User/Group), Start date, Target date, Notes.
Task	An actionable activity.	Description, Responsible person (User/Group), Access principals (User/Group assignees), Start, Due, Priority, Progress, Completed at, Notes.

ID	Requirement	Acceptance criterion
R-028	Activity Access principals identify involved users/groups and their ownership rights. Task assignees are exactly the users/groups in Access principals; Responsible person separately coordinates the activity.	A group can be responsible for performing a Task through Access principals. Changing assignees changes the same ownership list through the shared security writer. Foreign access grants permissions without assigning work. Responsible references grant no rights; there is no separate Task assignment field.
R-029	Project-management input aids remain configurable by Designers.	Supplied status suggestions Open, In progress, Done and Canceled can be configured via Type/Status mappings. Priorities are editable options rather than hard-coded behavior.

Projects, Cases and Tasks are supplied by the Projects module, with semantic UUID field bindings, protected structure and editable common form proposals. Domain fields initially remain optional. General contains Keyword and Description. Projects, Cases and Tasks pair their Details group (Record number, Responsible, Access principals) with Schedule. Projects/Cases show Start date and Target date; Tasks show Start, Due, Progress and Completed at in Schedule & progress. Primary association, Classification, relationship lists and final Markdown Notes follow. These are editable starter layouts. Task Priority is a configurable single-choice input aid. Responsible accepts a User or Group and grants no content rights. Activity assignees use the graded User/Group owners in Access principals. Task Priority belongs to Schedule & progress, immediately before Progress.

Project Target date cannot precede Start date; equal dates are valid. Task Start/Due use the shared temporal codec (date, instant, zoned); both remain independently optional. If both exist they use the same form and Due is strictly later than Start. Date-only values never imply midnight; zoned values retain wall time, named zone and an explicit overlap occurrence. DST gaps are rejected. Changing display settings does not rewrite domain time. The same codec is reserved for later Appointments/Vacations without installing these objects now.

Task Status options can carry an explicit meaning: Open, In progress, Done or Canceled, independently of translated labels and Type scopes. No status/default is forced. Done requires Progress 100 and Completed at; another or empty Status permits neither 100 nor Completed at. Progress otherwise remains optional, an integer 0–99. Selecting Done visibly proposes 100 and the current completion instant; the instant remains editable. Leaving Done clears Completed at and clears Progress only when it is 100. These proposals affect the local draft and persist together through ordinary Save with the same field rights, source version and per-field journal transaction. API/MCP supply the consistent final values explicitly. Configuration changes preflight current and recycled Tasks. Series, attendees, organizer, invitations and notification delivery remain later work.

Potential later nesting of Projects, Cases and Tasks

Outside V1, with no release assignment: evaluate same-type nesting as Subprojects, Subcases and Subtasks (Unterprojekte, Untervorgänge and Unteraufgaben). These remain records of the existing object types, rather than additional supplied object types.

ID	Requirement	Acceptance criterion
R-062	A potential later extension allows Projects within Projects, Cases within Cases and Tasks within Tasks.	Before implementation, specify how same-type parents coexist with Primary association and its tree, prevent cycles and define reparenting and lifecycle behavior. Any aggregation of dates, progress or completion needs an explicit rule; nesting does not itself grant access. This is an exploration, not part of V1 or an implementation commitment.

6.3 Domain profile completion and functional boundaries

For the object types outside the five standards-aligned profiles in section 6.4, supply lean, usable starting templates: shared platform fields, only the essential additional fields and a small set of meaningful relationships. Preserve already agreed domain fields/rules; do not expand templates into comprehensive industry models. Start optional unless a field or relationship is necessary for the agreed domain meaning or integrity. Use configurable input aids and editable form proposals rather than hard-coded specialist workflows or speculative automation.

Workspace Designers and Administrators can tailor these templates through the existing extension/configuration mechanisms: add custom fields and relationships, configure intended options/requiredness and arrange forms. This does not give ordinary Users configuration rights or remove the structural protection of module-supplied definitions. Future refinements remain separately specified; the lean baseline still needs clear validation and acceptance criteria.

Before implementing each supplied profile, specify:

• Its purpose, German/English labels, stable technical identity and module memberships, using the catalog above.
• Its minimum scalar fields: technical names/types, translations, applicability, initial values, initial requiredness and intended configurable input aids. Reuse shared platform fields instead of redefining them.
• Its supplied relationships: object pair, both side labels, direction, cardinality, endpoint conditions and any required context. Do not invent object types or mandatory module dependencies to satisfy a relationship.
• Its domain validation/derivation rules, the boundaries of protected definitions and configurable behavior, and its initial form proposal and declared fixed-core/customizable-extension boundary per contributing module.
• Observable acceptance criteria for creation, editing, linking, rights, journal history and lifecycle through UI/API/MCP. Record the specification status separately from implementation and acceptance status.

The 11 additional Contacts & Relations objects marked Next version are deferred together with their supplied fields and relationships. The five V1 objects are Contacts, Distribution lists, Projects, Cases and Tasks. Appointments, Vacations, Resource plans, Risks, Time entries and Goals are later scope, including their supplied fields and relationships. Initial profile proposals for the complete target catalog are specified in the appendix, alongside the five standards-aligned profiles; implementation and the identified domain-contract decisions remain open. Profiles can be refined and implemented incrementally. Domain-specific functions need explicit requirements and acceptance criteria: Time entries do not imply billing, Campaigns/Distribution lists do not imply automated bulk sending, and Vouchers/Line items do not imply a complete accounting engine. These functions are outside the current baseline unless separately agreed. Appointments and Vacations do not change the exclusion of calendar views, invitation delivery or notification delivery.

Documents, Emails and Phone calls as supplied object types belong to the later Documents & Communication module. A planned Voucher, Contract or Contact report is a structured data record, not a file-upload or mail-transport capability. Uploads, attachments and import/export remain excluded. The later module must separately specify file/content storage, external references and receiving/sending behavior before those functions are committed.

6.4 Standards-aligned contacts, calendars and tasks

The domain profiles for Contacts, Distribution lists, Appointments, Vacations and Tasks must support an explicit, vendor-neutral standards mapping. This is an accepted model-design constraint, not implemented import/export, synchronization, calendar UI or a claim of full RFC conformance. ADR 0031 records the architecture and reference specifications. Existing requirement IDs remain unchanged; this elaborates R-003–R-006, R-012, R-024–R-029 and R-041.

Object	Standards basis	Required model distinction
Contacts	vCard 4.0; JSContact as an additional JSON reference	Structured name components and formatted name; repeated labeled/preferred emails, telephone numbers and international addresses; birthdays with an unknown year. Map Contact kind, Organization relationship and Identities explicitly; CRM Keyword is not necessarily the formatted contact name.
Distribution lists	vCard group cards (KIND:group, MEMBER)	Explicit group identity and membership references, separate from contact categories, user/security groups and mail delivery.
Appointments	iCalendar VEVENT; JSCalendar Event as an additional JSON reference	Date-only versus timed values, event time-zone semantics, exclusive end, recurrence master/occurrence exceptions, organizer, attendees, participation response, event status and free/busy effect.
Vacations	Calendar projection using VEVENT	Retain the Vacation record identity and project its absence interval with the same date/time rules as Appointments. Leave application, approval and entitlement are separate domain behavior, not calendar status.
Tasks	iCalendar VTODO; JSCalendar Task as an additional JSON reference	Optional start/due values, date-only versus timed values, progress, completion timestamp, recurrence identity and explicit mapping of configurable status/priority. Task status and attendee response remain distinct.

The appendix provides concrete proposed fields, rules, forms and acceptance cases; ADR 0032 now defines the structured storage/contract architecture, with nine Contact codecs and relationship attributes implemented locally; the common temporal codec is implemented; recurrence/calendar parties and complete exchange-profile coverage remain open. The selected collection model uses typed structured fields under ADR 0032; generic Date/Date-time fields do not by themselves represent partial birthdays, domain time zones or recurrence exceptions. A partial birthday must not invent a year. UTC instants alone do not preserve a recurring event’s local-time intent. Personal display-zone changes must not rewrite an event’s zone; floating local times require an explicit supported representation or a reported unsupported value, never silent conversion using the viewer’s zone. Existing timestamp API rules in section 3.3 remain unchanged until dedicated domain contracts are specified.

Define each supported standard profile before claiming support: exact versions/extensions, mandatory and optional properties, cardinalities/types, field and relationship mappings, configured status/priority mappings, unsupported-data behavior and observable round-trip acceptance. Consider current vCard extensions and task extensions explicitly, without assuming every published extension is implemented. JSContact/JSCalendar are complementary design references; selecting them does not silently replace the existing application API contract or promise JSON exchange endpoints.

Future synchronization uses CardDAV for contacts/groups and CalDAV for calendar events/tasks, subject to the peer’s advertised capabilities and tested profile. Plan explicit mappings to remote address books, calendars and task collections; stable exchange UIDs and per-connection external identities/versions are separate from record UUIDs, record numbers and optimistic versions. Define conflict resolution, deletion propagation and prevention of duplicate/echo writes before enabling bidirectional writes. The eventual connector’s writes must use the shared API/MCP application rules and journals with the acting user’s current rights.

Product-specific behavior must not redefine the domain model. Nextcloud is one possible interoperability test peer, not the specification authority or a required dependency. A peer that exposes contact groups differently does not make Distribution lists into Categories in xObject. Unsupported mappings must be visible; preserve xObject-only fields/relationships and safely retained external properties, or refuse a destructive round trip instead of silently dropping or reinterpreting values. External attendees, group members, sharing flags and privacy classifications never grant xObject permissions automatically. External references do not enable uploads, remote resource fetching, reminders or invitation delivery implicitly.

Acceptance for domain delivery checks preservation of structured/repeated contact data, unknown-year birthdays, explicit group membership and separation from categories; date-only/exclusive-end intervals, domain-zone intent across DST and viewer-zone changes, and recurrence/exception identity; and tasks without dates with distinct progress/completion/status semantics. Future synchronization acceptance additionally checks stable identity, round trips, stale/conflicting updates, deletion handling, peer capability limits, permission enforcement and retention of unmapped data. These are acceptance targets, not completed tests. Transport, import/export, calendar views, scheduling messages and notification delivery remain outside V1.

7. User experience

ID	Requirement	Acceptance criterion
R-030	Every type provides a searchable, sortable table with Type/Status/Category filters and personal column settings. V1 persists column visibility; personal column order and widths are deferred to V2.	Column visibility persists for the respective user in V1. V2 additionally persists order and widths. Type/Status/Category filters combine multiple selected values with OR within each field and AND between fields; an explicit empty-value choice is available. Category matches at least one selected value, using stored ancestor closure for trees. Type filters scope Status choices; incompatible retained Status filters are cleared in the UI. Search/filter/order/page state is URL-based. Filtering and sorting do not expose restricted records or values; field visibility is applied before counts and pagination.
R-031	Record details provide a form, Journal and Dossier. The active Projects module additionally provides Primary association and its expandable hierarchy tree. Module contributions use one common object form; supplied Contact cores depend on Contact kind.	A user opens the same record from two modules without changing its identity; required missing fields follow R-006. Dossier includes accessible incoming/outgoing links and Primary association.
R-032	The Projects tree starts at the currently opened record and is generated exclusively from real Primary associations, descending from parent to child.	A direct Contact Task appears directly under the Contact. A Project view begins at that Project, a Case view at that Case. Missing levels are not invented. Compact rows show only authorized status captions. Expand all loads remaining pages/branches sequentially within the same limits, supports cancellation and ignores late responses after cancellation; Collapse all closes the branches and restores root focus.
R-033	The tree is available only with the active Projects module. General/custom links do not generate tree branches; defensive traversal limits and per-record permissions apply.	With Projects disabled there is no Tree tab and the shared tree API/MCP operation is unavailable. Parallel General/custom links do not duplicate Primary children; these links remain available in the Dossier.
R-048	Workspace navigation has configurable module sections, object entries and filtered child lists. Administrators/Designers manage workspace defaults; users manage their personal arrangement. Resources is initially visible and can be hidden as a whole block.	Order and visibility persist through UI/API/MCP with optimistic versions and atomic journals. Shared Contacts appear in both modules with the same records and separate navigation identities; Organization/Contact-person/Individual lists apply authorized filters before counts/paging. Sort with pointer or keyboard controls; restore inherited defaults without data loss.

Short save/copy/revocation results use one application-level Toast surface. Field/API errors, security guidance and unsaved changes remain in context; record drafts have one footer notice across tabs. Record-list, Dashboard and Dossier menus expose currently permitted Duplicate/Recycle actions; header further-actions include Copy ID.

Navigation structure, permissions, persistence, filtered Contact lists and shadcn composition are specified in ADR 0033.

7.1 Browser identity, installation and freshness

ID	Requirement	Acceptance criterion
R-059	The browser application provides installation identity, icons, contextual/neutral titles, theme/language integration and safe record-link sharing.	A valid standalone manifest uses one stable identity per origin. Private routes return only escaped generic preview metadata and noindex hints. Copy/share omits transient or secret parameters and grants no access. An available build requires an explicit reload with draft protection. Installation provides an online application shell.
R-060	Committed web/API/MCP changes update open authorized views without a full page reload and preserve local drafts.	Failed/rolled-back and read-only requests emit no change signals. Current rights filter signals and follow-up queries; reconnect/focus resynchronizes state. Clean forms adopt new versions; dirty forms retain edits, block stale saves and offer explicit conflict review. Settings/definition refreshes defer until save/discard. Connection loss and available app updates are visible.
R-061	Later, explicitly configured public viewing may expose selected workspace/record content and appropriate public previews.	Define anonymous principals, object/field permissions, lifecycle/revocation, indexing and preview-cache policy before enabling it. Existing private sharing remains authorized-only. This is beyond V1.

ADR 0036 defines the implemented private browser shell, bounded live transport and draft behavior. Public reading, public workspaces and record-specific public previews remain later scope. Browser/OS installation and native sharing support follow the client platform; V1 adds no offline business-data cache.

7.2 Planned record browsing within a list

Later, outside V1 and without a release assignment, record details will offer Previous/Next navigation within the list from which the record was opened.

ID	Requirement	Acceptance criterion
R-063	Browse between records in the detail view using the originating list’s filters and sort order.	Previous/Next follows the complete filtered, ordered result, including across table pages, and respects current record/field rights. Preserve the list context when returning, guard unsaved changes before switching records and disable navigation at the respective result boundary. Directly opened records without a list context must not silently use an unrelated list.

8. Journal and lifecycle

ID	Requirement	Acceptance criterion
R-034	Each changed field produces a separate journal entry with a stable field reference, old/new value and common change ID for the save operation.	A save changing Status and Description yields two entries with different field references and the same change ID. Renaming a field does not prevent filtering its historical entries.
R-035	Relationship changes and lifecycle actions produce their own entries. A relationship event is accessible from both participating records’ journals.	Adding/removing/changing a relationship produces one centrally identifiable event displayed from both authorized record contexts.
R-036	Journal metadata records timestamp, responsible user, access channel, optional agent, affected object and action. Changes and journal entries are atomic.	A transaction failure leaves neither changed content without its journal nor a committed journal describing an uncommitted change. Agent actions identify both user and agent context.
R-037	The journal is system-written, not manually editable even by Administrators. Record views show newest first and load older entries as needed; configuration/permission changes appear in a system journal.	Manual update of a journal event is unavailable through UI/API/MCP. Administrators can read the entire journal; other users’ access follows their effective permissions.
R-038	Recycled records retain fields, relationships and journal history but leave normal lists and selectors. Other records are not cascaded into the bin or deleted.	Recycling a Project leaves its Cases and Tasks intact and marks the unavailable Primary association without leaking protected parent data.
R-039	Restore requires Full access and reuses still-valid relationships. Permanent deletion requires Full access and confirmation.	An unconfirmed permanent-delete request changes no data. Restore does not silently create invalid relationships. No automatic permanent deletion is enabled in version 1.
R-040	Permanent deletion removes the live record and its operational relationships while retaining its complete immutable journal for installation Administrators. Non-Administrators, including Designers and users with object-level Full access, receive only a content-free deletion notice in authorized contexts. No automatic journal cleanup is enabled initially.	Administrators can inspect historical field values and relationship snapshots after deletion, including from linked-record history. Other users receive no deleted Keyword, record number, field values or endpoint snapshots through UI/API/MCP, search, filters, counts, summaries or details. A deletion notice appears only in an otherwise authorized context where the event was visible; deletion never reveals a previously hidden record/event. Other records retain their independent history. The delete confirmation states that history remains available to Administrators. The dedicated API/MCP operation and role-aware history projections are implemented locally.

User-bound external access

External applications and agents use owner-bound access tokens with current user permissions, selected REST/MCP channels, optional read-only restriction and mandatory expiry. Creation requires an interactive session and current password; secrets are shown once. Owners manage their credentials and Administrators may inspect/revoke other users’ credentials. Password changes and deactivation revoke them. API v1 has generated portable input/output schemas, machine-readable errors and explicit major-version negotiation shared with MCP; the typed client handles bearer-only HTTPS requests without automatic mutation retries. ADR 0034 owns the security/contract decision; API and MCP access owns usage and operation details.

Permanent deletion and retained history

The recycle bin retains the complete record, relationships, security and journal and supports authorized restoration. Confirmed permanent deletion removes the live contents and operational links and ends restoration through the application; it does not erase journal contents. Retained journal/identity references must not keep the record in normal lists, selectors, relationships or cardinality slots. Dependent records are not deleted in a cascade. Required-context and other dependency conflicts must be resolved explicitly before deletion can commit.

The retained history is visible in full only to installation Administrators. For all other users, including Designers and object-level Full users, any otherwise visible event referring to the permanently deleted record is projected as a neutral “Record deleted / Datensatz gelöscht” notice. This applies equally in the deleted record’s retained history, system-journal projections and surviving linked-record journals. No historical values, names, numbers, relationship attributes or deleted-record security contents are disclosed through alternate detail views or query channels. Existing authorization still controls whether a context/event is visible at all; a tombstone is not a new directory of deleted records. The minimal identity/authorization metadata required for that decision may be retained separately from live business contents. Other records’ unrelated journal entries remain unchanged.

Deletion, operational edge removal, reduced deletion-event creation and the retained-history visibility boundary must commit atomically. Normal journal entries remain immutable. A separate content-and-history erasure capability may be evaluated later; it is not part of this deletion operation or the V1 delivery commitment. The confirmation must explicitly state that Administrators retain access to the history. R-039/R-040 are implemented locally: the registry stores a deletion timestamp/actor, retained policy and frozen field/event/context eligibility; the live row and edges are removed. Current rights and frozen prior eligibility jointly govern non-Administrator deletion notices. Full retained history is available through the Administrator history area in the recycle bin and the shared API/MCP journal operation.

The Administrator history overview identifies deleted records with their last display Keyword, retained as private tombstone metadata before live deletion, including derived Contact names. It supports Keyword/ID search, object filtering and sorting before counts/pagination, and uses the shared Journal for field/relationship inspection. This caption is never exposed in ordinary users’ deletion notices.

9. Architecture, delivery and quality

ID	Requirement	Acceptance criterion
R-041	The architecture is API-first and metadata-driven with one shared backend application layer. Every application capability is exposed through API and MCP.	Definition changes, record changes, configuration and lifecycle actions can be exercised without UI-only privileges. The same validation, permissions, confirmations and journal rules apply in all channels.
R-042	Agents act with their user’s effective rights. Local accounts are supported initially; SSO is later.	An agent for a restricted user cannot gain access by changing the access channel. An agent for an Administrator has the corresponding Administrator rights.
R-043	Use PostgreSQL, TypeScript/Node.js, React/TypeScript/Vite, Tailwind CSS and shadcn/ui in a modular monolith. Git stores source and project documentation, not live application records.	The installed product operates without a Git account or user-owned repository. Concrete framework/package versions must be selected and tested before delivery.
R-044	Prefer standard shadcn components and variants, minimal custom CSS and semantic design tokens/CSS variables for light/dark theming.	Forms are composed from reusable components. Theme changes preserve readable contrast and visible focus. A runtime theme editor is not presumed to be supplied by shadcn.
R-045	Official self-hosting uses versioned prebuilt images and Docker Compose with xObject and PostgreSQL services.	A clean supported Linux host can install the published package, configure HTTPS, start services and create the first Administrator without building source or installing Node.js.
R-046	Release updates include controlled database migrations and consistent database/configuration backup with a tested restore procedure.	An acceptance run restores the release’s data/configuration into an isolated installation. Supported source data, schema and configuration are fully converted to the target model before serving the updated application. Application code uses only the target model; source-version handling belongs to dedicated upgrade tooling. Initially, all application processes and other writers are stopped during backup/migration; the target application starts only after successful schema/integrity checks. Failed migrations leave the application stopped until consistent recovery with the matching application version. Mixed-version rolling updates are outside the initial scope. Failed migrations do not produce a falsely successful upgrade result.
R-047	The full product, including Premium code, is open source under GNU AGPL version 3 only (AGPL-3.0-only). Version 1 is entirely Community with its complete agreed scope and no Premium feature gates. Future official Premium activation may accompany support/maintenance offerings.	The release declares its license and includes the corresponding source availability. V1 UI/API/MCP expose the same Community scope. Jürgen Schadek is the personal licensor/maintainer under ITextreme; contributions use the same license with DCO sign-off. Future Premium allocation and service terms are separate later decisions.

9.1 Delivery conventions

• Local development uses a monorepo with apps/web, apps/server, packages/contracts, deploy and docs; these directories now exist in the local prototype; the independent public website lives in apps/site. Their existence is not evidence of a release package.
• GitHub is the leading public remote. The second Forgejo remote is private. Push intended branches/tags separately to both and verify them independently; do not maintain divergent development histories or assume Git transfers platform metadata.
• OpenProject owns operational planning. Git owns this PRD, glossary, ADRs, source, configuration, documentation, changelog and public roadmap. Detailed task status does not belong in this PRD.
• Use Conventional Commits, Semantic Versioning, Keep a Changelog, ADRs and Diátaxis as established project conventions. Use IREB/CPRE terminology and a product glossary.
• Public entry points: Documentation at https://docs.xobject.org/, Changelog at https://xobject.org/changelog/ and Roadmap at https://xobject.org/roadmap/. The application sidebar links to them above the user menu, opening a new tab. URL selection is distinct from publication of these pages.
• Public product website: Astro. Public documentation: Astro/Starlight. Both are static sites delivered with Caddy. CHANGELOG.md and ROADMAP.md are reused rather than maintained as duplicate copies. The public roadmap is curated from OpenProject.
• Releases have explicit tags, reviewed release notes, tested images, Compose configuration and upgrade/restore instructions. Supported documentation versions remain accessible under versioned paths. GitHub platform metadata needs a separate backup mechanism.
• Work in small end-to-end changes, review through pull requests and validate relevant acceptance criteria. No performance target, supported-host matrix or scalability claim is established until measured and specified.

Personal settings are ordered Profile, Account & security, Appearance, Language & region. Profile edits the own display name; Account & security shows the read-only sign-in email. Profile-name changes use the common journaled API/MCP operation. Personal Account & security settings allow verified local password changes and management of the signed-in user’s own active sessions through the same API/MCP rules, without exposing bearer credentials. Current sessions are protected from the other-session revocation actions. See ADR 0010 for the local implementation and remaining production authentication decisions. This elaborates R-042 and the journal rules without adding a requirement ID.

Workspace Appearance is shared by all users of that workspace. Administrators and its Designers configure a shadcn base color scheme, a separate accent Theme, an independent chart palette, separate optional six-digit hexadecimal primary and secondary overrides for Light/Dark, corner radii, an interface font and a heading font from the fixed shadcn-based catalog, including locally served Orbitron. Headings can inherit the interface font. A fixed Lucide icon identifies the workspace in its switcher; an own-logo upload is visibly prepared but disabled until image storage/upload exists. Menu surfaces support standard/inverted (dark), each optionally translucent, and subtle/bold menu accents. Interactive light/dark previews use real standard sidebar, card, table, input, button, dropdown and selection components, including keyboard navigation, active/selected states and disabled entries. Portalled preview menus use the draft interface font and mode. Inline advisory checks flag insufficient custom-primary contrast for normal links and focus borders; they do not change the configured colors. Menu settings apply to the current workspace’s dropdowns, Select popups and command palette; native platform selects retain their native popup rendering. Custom font uploads, external font services, arbitrary CSS and component-style switches are excluded. The UI previews light and dark locally; Save publishes the shared design, while Reset restores the current saved state. User and header light/dark/system mode remain personal and browser-local. Workspace changes must replace the previous workspace’s tokens, including portalled overlays; leaving the application restores the default design. API/MCP enforce the same workspace authorization, strict values and optimistic version checks, with one journal entry per changed property and atomic rollback. A no-op does not increment the version or create journal entries. See ADR 0011.

Installation setup and deferred profile features

The container installation creates the first Administrator through a one-time interactive setup command inside the application container. The operator supplies name, email and password, with hidden password input, then signs in normally. There is no shipped default account or public first-visitor claim flow. The local npm run admin:create and container setup commands share the same atomic first-account writer. Environment variables are supported for controlled automation; an existing installation cannot be claimed again. See the operator guide.

Changing the sign-in email is deferred until outgoing email is available. The agreed flow requires the current password and an available new address, sends a single-use expiring confirmation link to the new address, retains the old address until confirmation, then atomically updates/verifies the email and journals the change. Notify the previous address and revoke other sessions after completion. User identity, permissions, relationships and history retain the same user ID. The mail flow, delivery/retry handling and corresponding shared API/MCP operations remain later implementation work; the current profile email stays read-only.

The Profile page reserves a profile-picture area with an initials fallback and an explicitly disabled upload action. Upload, storage, validation, removal and application of an image remain deferred until the upload facility exists. The existing auth image field is not currently used to load external image URLs. This visual preparation does not add file uploads to the current implementation or alter the general version-1 exclusion of uploads/attachments.

9.2 MCP interoperability and V1 acceptance

R-041/R-042 require a provider-neutral MCP interface. Protocol compatibility depends on the connecting client, its negotiated protocol revision, supported capabilities, transport and authentication, together with a model capable of tool use. A provider/model name alone is not a compatibility guarantee. Keep the xObject API version independent of the dated MCP protocol revision.

The current local implementation uses the official TypeScript server/client SDKs 2.4.0, MCP 2026-07-28 discovery/envelopes and the SDK’s stateless 2025-era serving, personal Bearer credentials and resource-bound OAuth authorization, shared-contract output schemas, structured results and JSON text. Protocol and permission-aware Skills tests use real SDK clients. Passing local integration tests is not provider end-to-end acceptance. The following delivery criteria distinguish implemented protocol behavior from remaining provider work:

• Align the implementation with MCP 2026-07-28 using a supported official SDK, including discovery, request/version metadata and result envelopes. Record the exact SDK/client/model/protocol tuple used during acceptance; verify supported-version negotiation rather than assuming every client already implements the latest revision. Avoid bespoke compatibility transports or provider-specific business rules.
• Add the MCP HTTP authorization profile: OAuth 2.1 with Authorization Code/PKCE, protected-resource and authorization-server discovery, appropriate client identification/registration, resource/audience-bound tokens and safe consent/expiry/revocation behavior. OAuth-issued access must resolve to an xObject user and the same live permissions/journal rules. Keep personal credentials for explicitly configured clients. This requirement does not depend on external SSO; SSO remains later scope. ADR 0034 owns the authorization refinement.
• Expose tool output schemas and structured results consistent with the shared contract, retaining JSON text where required by the supported protocol/client. Supply actionable descriptions and accurate read-only/destructive/idempotency hints. Annotations and client approvals never replace backend permission checks or required destructive confirmations.

V1 live provider acceptance is limited to OpenAI. Codex with an available tool-capable OpenAI model is the primary acceptance path. ChatGPT plugin/app integration is an additional path when the account/workspace enables it; a Responses API run is additional coverage only with separately available API access. An existing OpenAI subscription does not prove API access or availability of every product feature. Do not purchase additional provider subscriptions or infer coverage for unavailable paths. Protocol/contract tests with the official MCP SDK remain provider-independent and require no model subscription.

Acceptance covers discovery/tools/resources where supported, structured successful results and errors, read/search/create/edit/link/lifecycle operations, current User/Designer/Administrator and field limits, read-only credentials, token expiry/revocation and journal provenance. Use fictional test data and reviewed user-bound credentials. Client-side confirmation and backend destructive confirmation are checked independently. Cloud-side tests need an explicitly authorized reachable HTTPS endpoint or supported private-connectivity path; a service bound to localhost is reachable only from a local client without such a path. Capture the tested client version, model, negotiated revision, transport/authentication, supported features and results; report unavailable capabilities as not tested. The primary live Codex path has passed the recorded provider exercise; its exact client/model/protocol and supported skill paths define the accepted scope.

Anthropic Claude and Google Gemini offer MCP-capable client/API paths, but remain documentation-assessed and untested for xObject. Their model variants, hosting paths and optional capabilities are not part of V1 acceptance. Additional providers can be validated later without changing the business model or weakening permissions. See the client compatibility reference for sources and current boundaries.

9.3 Supplied agent skills

V1 supplies one shared xObject foundation skill and complementary skills for Contacts & Relations and Projects & Tasks. A model-design workflow complements the foundation for users permitted to configure object types, fields and relationships. Skills contain a SKILL.md with discovery metadata and workflow instructions, plus references when needed. Keep one versioned source per skill and load detailed instructions on demand rather than inserting every workflow into each tool description.

Skill scope	Intended workflow
Foundation	Discover workspace/module/object capabilities, inspect the live model, select tools, validate changes and present confirmed results.
Contacts & Relations	Search before creating, use the configured Contact kinds, Organization membership and Identities, and preserve the agreed contact semantics.
Projects & Tasks	Create/review Projects, Cases and Tasks, handle the actual Primary chain, current status/completion rules and assignment through Access principals.
Model design	Inspect existing definitions and dependencies before configuring fields/relationships, apply required confirmations and verify the resulting metadata and journals.

Serve skills through the standard optional io.modelcontextprotocol/skills extension using the official SDK, negotiated discovery and normal resource reading. Advertise only implemented capabilities. Discovery and reads use the current authenticated user’s permitted workspace/module context; supplied workflows adapt to active modules and current definitions. Discover field identities, input aids, requiredness, relationships and rights at runtime; do not embed installation-specific UUIDs or assume user-defined fields remain unchanged. Skills guide the normal API/MCP operations; the backend continues to enforce all access, validation, version and journal rules.

The same source skills may additionally be distributed with the MCP connection in an optional OpenAI plugin package. Direct MCP-skill discovery, plugin-packaged skills and ordinary readable resources are different client capabilities; availability of one does not imply automatic discovery, installation or execution through another. Verify the available OpenAI client’s actual discovery/loading/activation behavior during section 9.2 acceptance. Other provider/host support remains untested. Record unsupported or unavailable skill paths explicitly. The standard Skills endpoint and its four workflows are implemented and tested locally, including live-right changes, direct-read denial and digest verification. The optional portable plugin is packaged and schema-checked locally from the same source files. The live Codex exercise used all four workflows through MCP resources and separately used installed Foundation/Projects plugin instructions. Native MCP Skills activation was not exposed/negotiated by the tested client; resource/package loading does not certify that path. See provider acceptance.

9.4 Later target — connected context, knowledge and agent work

The requirements in this section elaborate the product vision beyond V1. They are not implemented delivery claims, have no assigned release and do not alter R-001–R-048 or the V1 acceptance scenarios. Detailed contracts and architecture decisions are required before implementation. Existing integrations, schedulers, source repositories and execution tools should be reused where they satisfy these requirements; this PRD does not select a second search engine or a new agent runtime.

Context and knowledge

ID	Requirement	Later acceptance criterion
R-049	An authorized user or agent can obtain a bounded working context from a record, including relevant relationships, source references, decisions, results and open work. Context discovery is available through UI, API and MCP.	Starting from a Contact, Project or another supported record identifies the leading sources and relevant permitted context without requiring the caller to know each storage location. A context package identifies its retrieval time, available source versions, freshness limits and omissions. Unavailable or stale sources are explicit; they are not represented as complete current knowledge.
R-050	Context discovery combines exact full-text/identifier lookup, semantic retrieval and relationship traversal with meaningful filters and attributable results. Current source and field rights apply before previews, counts and context assembly.	A question about a previous decision can return its rationale, supporting sources and related work. Results show source links and understandable ranking/match evidence. Revoked access removes contents from all query projections, including semantic results. A change cursor can retrieve additions, changes and authorized deletion information without reloading the complete corpus; expired cursors require an explicit resynchronization.
R-051	Knowledge work distinguishes sources, conversation notes, working notes, focused insights, reusable knowledge and personal journal entries. Processing state, review/confirmation, freshness and validity remain separate properties.	A user can capture free text, process it from an inbox state and derive a source-linked result without forcing every sentence into a field. Typed relationships can express derived from, supported by, contradicts and supersedes. Completion does not imply verified or current knowledge. The personal journal is distinguishable from the immutable technical change Journal. Any later import requires an explicit mapping of source kinds, states and relationships, including unresolved values.

External references must retain source identity and attribution. Any cached content, index or context snapshot must have a declared update/deletion policy and enforce current access; source permissions and installation/workspace boundaries cannot be bypassed by a previous retrieval. Ordinary records and external documents remain data. Instructions found inside them do not become authorized policies or skills by being retrieved.

Knowledge records hold useful conclusions, sources and work state. Internal reasoning traces are not a knowledge or execution-storage requirement. Search architecture, indexing technology, source connectors, ranking, context budgets, graph depth and cursor retention remain design decisions.

Profiles, delegation and execution

ID	Requirement	Later acceptance criterion
R-052	Agent profiles, rules and reusable skills have identifiable versions, provenance, scope and publication/withdrawal state. Definition editing and authorization for unattended use can require different rights.	A job identifies the approved profile/rule/skill versions actually used. A draft or withdrawn definition cannot silently replace its approved version. One canonical source owns each definition; generated client adapters and distributed packages retain that provenance. Supplied software skills and user-maintained definitions have explicit update/override rules. Runtime and project instructions retain their precedence; profiles and skills grant no access.
R-053	Delegation separates the business Responsible reference, selected agent profile and authenticated authorizing user. Effective authority is bounded by current user rights, approved job scope and the runner’s allowed capabilities.	A user delegates a defined result or subtask with explicit allowed actions. The backend derives the acting user from authenticated authorization; an agent cannot select a more privileged identity. Profile changes do not grant credentials or tools. Revocation, reduced user rights or expired authorization stops subsequent unauthorized actions. An unclear or broader action requires a new decision rather than implied permission.
R-054	A concrete agent job is separate from its execution attempts, recurring automation and produced business contents. Jobs preserve goals, source context, questions, decisions and a concise resumption point.	A job can be processed partially, interrupted and resumed by another eligible runner without relying on a private chat transcript. Each attempt records runner/model identification, actual definition versions, start/end, progress, errors and result references. A stale context or conflicting record version is resolved explicitly. Results live in appropriate linked records; an execution log does not become a competing knowledge store.
R-055	Recurring automations specify schedule/time zone, enabled/paused state, job template, execution authorization and a policy for missed occurrences. Existing schedulers can implement the agreed contract without duplicate schedules.	Concurrent scheduling/claim requests create at most one job for a scheduled occurrence. A timezone transition, missed occurrence, paused definition or withdrawn authorization follows its declared policy. Users can inspect the planned occurrence and actual execution separately. An offline runner does not create a false promise of timely execution; deployment and availability targets are documented.
R-056	Job execution uses authenticated runner registration, eligible capability selection, atomic time-limited claims, renewal, bounded retry and controlled cancellation/recovery. State-changing external actions need protection against duplicate effects.	Two runners cannot concurrently obtain a valid claim for the same attempt. An expired or superseded claim cannot authorize further writes. Recovery inspects uncertain prior action outcomes before retrying, using idempotency/reconciliation where supported. A lease alone is not treated as exactly-once external delivery. Failures and retry limits remain visible, and cancellation defines what can still finish.
R-057	A common work view presents delegated work, waiting questions, attempts, results and changes to authorized people and AI clients, including from a usable mobile interface.	From a business record, users can distinguish queued, running, waiting-for-user, interrupted, failed, cancelled and completed work and navigate to its results and permitted history. A required decision pauses dependent work. Another team member can understand what was done and what remains under their own rights. Journal provenance identifies the authorizing user and agent/execution context without disclosing credentials or internal reasoning traces.

These concepts do not prescribe seven additional freely editable object types or a particular queue schema. Claims, authorization, scheduling and execution transitions require protected backend operations. Displayed states and descriptive fields alone cannot enforce them. Existing task assignment through Access principals remains unchanged; selecting an agent or granting foreign access does not assign a human participant or notification audience.

Client integration must distinguish discovering/reading a skill, actual host activation and successful execution. A provider-neutral, minimal bootstrap can locate an approved profile, check capabilities and load context; its presence cannot prove that a client supports native skill activation or unrestricted profile switching. Each supported client/runner needs its own acceptance evidence. Credentials remain in the designated secure credential mechanism, separate from profiles, skills and job contents.

Sovereignty and operation

ID	Requirement	Later acceptance criterion
R-058	The connected work model remains self-hostable and portable, with documented interfaces and a full-fidelity export/recovery path for user-owned contents, definitions, relationships, files and retained history. External processing is controlled separately from storage.	An operator can preserve and restore a consistent installation and export the authorized data needed for migration without a mandatory hosted-service account. Source identities, relationships and history are retained in a documented representation. Before contents are sent to an external model/service, the effective policy permits the recipient, data scope and action; an unauthorized route is rejected. Operator documentation states model/runner dependencies, costs, backup/restore and failure behavior. This later export capability is distinct from V1 backup/restore and is not a V1 import/export commitment.

Logical workspaces continue to follow R-001 and the installation-wide Administrator exception. Environments requiring separate administrative trust boundaries need separate installations and credentials. A common work view must not merge those security boundaries. Open source and self-hosting do not remove the operator’s responsibility for access, data processing, availability and maintenance.

Later end-to-end acceptance

Before assigning a delivery version, select a first workflow and measurable limits. Candidate acceptance spans an authorized user capturing work from a mobile client, delegating a bounded job, obtaining source-linked context, saving a linked result, interrupting an attempt and resuming it from another eligible runner. Verify competing claims, revoked access, unavailable/stale sources, pending user decisions and uncertain external-action outcomes. The user must be able to inspect the resulting state and continue without reconstructing the original chat. These are later acceptance targets, not completed tests or a selected pilot.

10. Remaining design decisions

These items require elaboration, not additional feature discovery. They must be resolved before implementing the affected requirement.

Area	Decision / affected requirements
Connected context and knowledge — later	Select the first end-to-end workflow and its measurable retrieval/freshness/latency limits. Define source authority, connector contracts, index update/deletion, context budgets, cursor retention and knowledge-state/import mappings. Reuse suitable existing retrieval capabilities. No change to V1 delivery scope. R-049–R-051.
Agent work — later	Define canonical ownership and release/update rules for profiles/rules/skills; delegated authorizations and revocation; job/attempt state transitions; runner registration and capability trust; claims/fencing, cancellation, retries and external-effect reconciliation; schedule ownership, missed-run behavior and actual client support. No runtime, scheduler or physical object catalog is selected by this target. R-052–R-057.
Portability and external processing — later	Specify full-fidelity export/schema and external-reference/media/history treatment, processing approvals, supported local/external model routes, operator availability/cost targets and migration acceptance. Keep the existing V1 self-hosting/backup requirements and Administrator boundary. R-058, R-001, R-045–R-047.
Workspace and security	User-bound API/MCP credentials, per-channel/read-only restrictions, expiry, owner/Admin revocation and password-rotation invalidation are implemented locally under ADR 0034. Database-backed login limits, session/cookie policy, trusted proxy handling and response headers are implemented and covered by the accepted browser and native-host checks. Section 4 ownership/foreign access is implemented locally under ADR 0027, including the resolver, graded/nested membership storage and rights UI. Representative-volume performance has a measured local baseline in the quality report; production acceptance remains open. Calendar/privacy projections and notifications remain later work; STANDARD templates and optional default groups need detailed design before enabling them. R-001, R-013–R-018, R-042.
Data representation	Release migration/restore packaging, references beyond user/group fields, remaining relationship/reference lifecycle rules; the current unreleased installation baseline is specified in ADR 0028 and database integrity/concurrency in ADR 0022; field/object definition lifecycle is specified in ADR 0009. Current typed storage, validation, Markdown and conversion rules are specified in ADR 0007. R-002, R-007–R-012.
Input aids	Translated descriptions/hints, typed creation defaults and supported scalar uniqueness are implemented locally under ADR 0030. Contact input aids and conditional name requirements are included in the locally accepted Contacts scope; classification dictionaries/defaults retain ADRs 0006/0007. Dedicated Contact-kind conversion remains a later extension described in the Contacts row below. R-009, R-010, R-012, R-024.
V1 domain profiles	Starting proposals for the target catalog are in the appendix; Contacts and Distribution lists as well as the V1 Projects/Cases/Tasks slice are locally functionally accepted. The reduced V1 scope contains five objects with supplied templates: Contacts, Distribution lists, Projects, Cases and Tasks. The 11 additional Contacts objects remain next-version scope; the six additional Projects objects, recurrence and calendar parties are later scope. Complete product-level acceptance and exchange-profile design separately. R-003–R-006.
Standards-aligned domain profiles	Implement the appendix’s proposed fields through ADR 0032’s selected structured storage/contracts architecture; complete versioned exchange profiles separately. Nine typed JSONB contact codecs, stable field-purpose bindings, whole-field rights and base Contacts/Distribution-list provisioning are implemented locally. Generic relationship attributes and both-endpoint field rights are implemented locally; calendar-party codecs, structured Contact references and sparse versioned recurrence overrides remain unimplemented; the common temporal codec and lean Projects/Cases/Tasks templates are implemented. CardDAV/CalDAV transport and bidirectional conflict/deletion handling remain later work under ADR 0031. R-003–R-006, R-012, R-024–R-029, R-041.
Contacts	The V1 Contacts/Distribution-list functional scope is locally accepted against R-024–R-027 and the domain-profile cases. Ordinary Organization replacement/removal already works and retains direct professional fields. The four guided Contact-kind conversion workflows, duplicate detection/merge and role-validity intervals are later extensions, not outstanding CRM V1 acceptance. Media upload and exchange/synchronization remain deferred. Released installation/upgrade tooling and full-product acceptance remain separate.
Relationships and modules	Object-level required Primary associations/ancestor levels, retained-record preflight and descendant validation are implemented under ADR 0024. An additional explanatory UI for module-related required-field dependencies is deferred beyond V1, without a version assignment; evaluate it only when a concrete module combination needs it. Existing shared required-field rules and backend validation remain unchanged. Shared-definition contributions, common object forms, retained deactivation/reactivation and additive template updates are implemented locally. Basic endpoint cardinalities, cycle prevention and concurrent preflight/activation are implemented under ADRs 0018–0024. R-003–R-007, R-019–R-023.
Journal and recycle bin	Recycling and guarded restoration are implemented locally under ADR 0029, retaining identities, edges and history. Confirmed permanent deletion, content-free notices for other authorized users, Administrator-only retained history including linked contexts, operational edge cleanup and user/channel/credential/agent journal metadata are implemented locally under ADRs 0029/0034. Overall release/scale acceptance remains separate. Current-rights record/field/endpoint journal projections are implemented under ADRs 0026 and 0027. R-034–R-040.
Interfaces and UI	The versioned REST/OpenAPI/MCP contract, typed bearer client and external credential issuance are implemented locally under ADR 0034. The primary OpenAI Codex path has passed the scoped live acceptance in section 9.2; additional client surfaces retain their explicit coverage limits. OAuth authorization, protocol alignment, structured results and supplied skills in section 9.3 are implemented locally. Remaining bulk-action semantics require their own specification. Personal table-column order/width persistence is deferred to V2; V1 retains the implemented visibility preference. The local Primary tree presentation is specified in ADR 0020 and its permission projection in ADRs 0026 and 0027. Local routing/query behavior, table navigation and shared appearance scope are specified in ADRs 0004, 0011 and 0016. R-030–R-033, R-041, R-044.
Operations	Local Node.js 24/Linux container, proxy configuration, backup/restore and fail-closed maintenance acceptance are implemented under ADR 0035. Native Ubuntu/AMD64 installation, trusted HTTPS, restart and isolated restoration passed; see the dated quality report. Final release-image verification and publication complete delivery. Supported-source migrations become required when a released predecessor exists. R-043–R-046.
Commercial	Jürgen Schadek personally is the licensor/maintainer under ITextreme. V1 is fully Community; contribution terms use AGPL-3.0-only and DCO. Future Premium allocation, pricing, activation and service/support terms remain later work. R-047.
Quality	Initial profile, data volume, p95 targets and measured local results are specified in quality acceptance. The primary OpenAI Codex client/model exercise is recorded in that report. The agreed Chromium/Firefox/Safari, responsive and targeted VoiceOver acceptance is complete within the quality report’s recorded scope. Native AMD64-host/HTTPS/recovery acceptance is also complete. Real-device coverage and full WCAG certification are unclaimed coverage limits, not newly imposed V1 gates. Verify the final release artifacts before publication.

11. Initial acceptance scenarios

These scenarios guide the first implementation slices. They are not a completed test report.

1. Object core: Create a workspace, custom type and field; save a record through API/MCP; confirm UI visibility and the journal. Verify a rejected input leaves neither a partial record nor journal entries. R-001, R-002, R-008–R-012, R-034, R-036, R-041.

2. Permissions: Execute section 4.8 through UI/API/MCP: object/field caps, graded ownership, foreign access on both group sides, nested/transitive paths, public/Personal/Confidential records, explicit overrides, revocation, fresh-installation parity and Administrator access. Keep future calendar/notification acceptance separate from version 1. R-013–R-018, R-042.

3. Contacts: Create an Organization, a sole-business Individual contact and separate Contact person records at Organizations A and B, linked through Identities and carrying distinct professional roles on their Contact records. Verify Keyword formation and field applicability. R-024–R-027.

4. Project context: Create Contact → Project → Case → Task and direct Tasks at Contact/Project level. Change a parent assignment; inspect derived context, tree, dossier and both sides’ relationship history. R-019–R-023, R-028–R-035.

5. Module catalog, shared forms and evolution: Activate each V1 module alone and both together; verify the five V1 catalog objects and agreed domain-profile acceptance. Verify that shared Contacts always use the same common form, identity, values, rights and history. Complete newly contributed required fields, reject conflicting contributions/unsafe conversions and preflight stricter rules. Deactivation retains data/history and shared-object usability through remaining active modules; unsatisfied dependencies block it. Planned later modules cannot activate as delivered features. R-003–R-007, R-023, R-031.

6. Lifecycle: Recycle a Project without cascading to its children, restore valid relationships, reject unconfirmed permanent deletion and verify complete retained history for Administrators and only authorized content-free deletion notices for all other roles after confirmed deletion, including linked-record history and API/MCP projections. R-038–R-040.

7. MCP interoperability: Complete section 9.2 using the available OpenAI acceptance path; prove current user/field rights, lifecycle confirmations, credential revocation and schema-correct results/errors. Record the exact client/model/protocol combination. Verify the supplied foundation/module skills and their actual client discovery/loading behavior under section 9.3. Other providers remain untested; SDK-only tests do not count as OpenAI end-to-end evidence. R-041, R-042.

8. Self-hosting: Install only the release package and images, create the first Administrator, back up an instance and restore it in isolation. R-043, R-045, R-046.

12. References

• IREB/CPRE glossary
• GNU AGPL version 3, with the version-3-only licensing declaration in the README.
• UUIDv7, RFC 9562
• Diátaxis
• Keep a Changelog
• Semantic Versioning
• Conventional Commits