Cross-Dotabase Derivations

Description

Cross-Dotabase Derivations project source rows into another Dotabase through explicit mappings, with both backfill and real-time event execution.

A derivation binding names the source and target, selects eligible lifecycle events, maps source values into declared target properties, and defines a deterministic identity for the projection. The service can sweep existing rows in bounded batches or react to new events. Repeated runs resolve the same target identity, so a backfill and the real-time path converge instead of creating duplicate rows.

User Story

As an operations lead, I derive a task or customer record from source knowledge and keep the projection current. I define which source rows qualify, how their fields map to the target schema, and the identity that makes each projection stable. I run an initial backfill and then enable the event binding. I walk away with a purpose-built operational view that updates predictably while target fields outside the derivation's ownership remain available for local work.

Extension Surface

Configurable: bindings choose source, target, event triggers, identity, and property mappings.

packages/dotabases/src/services/derivation-binding-service.ts manages this configuration as tenant-scoped records. Owners compose supported mappings and triggers; they do not upload arbitrary transformer code. The actual projection contract in packages/dotabases/src/services/derivation-service.ts keeps target writes inside Dotabase schema and lifecycle rules.

Capabilities & Limits

• Capability: Executes the scoped workflow described above through the cited live implementation paths.
• Capability: Preserves typed validation and applicable tenant, schema, lifecycle, or service boundaries.
• Limit: Derivation maps declared data; it is not an arbitrary code execution engine. A target's independently owned fields must remain untouched. The feature supports idempotent batch materialization, real-time event execution, stable source-to-target identity, and explicit field ownership. It cannot express open-ended computation or safely overwrite target data owned by another workflow. Both Dotabases and every mapped property must exist and remain compatible for a binding to run successfully.

Implementation Map

• packages/dotabases/src/services/derivation-service.ts
• packages/dotabases/src/services/derivation-binding-service.ts
• packages/db/src/schema/derivation-bindings.ts

Related Features

Uses Dotabase Workspaces and shares deterministic mapping principles with Deterministic Property Fill.

Operationally, these relationships preserve a clear ownership boundary around Cross-Dotabase Derivations. Neighboring features can invoke, supply, or consume its results, but `packages/dotabases/src/services/derivation-service.ts` remains the grounded implementation authority for this capability. That distinction prevents the catalog claim from widening into adjacent rendering, transport, or governance work. Teams can therefore combine the feature with the named dependencies while still diagnosing configuration, validation, and lifecycle behavior at the package boundary that owns it.