Implementation and evidence
Reconciled 5 October 2026. Tidemark is the data-layer architecture and reading map. This chapter replaces the superseded data implementation plan. It specifies evidence gates rather than a fixed quarter-long schedule, universal database choice or claim that the proposed platform already ships.
Current boundary
| Area | Present building blocks | Still requires implementation or qualification |
|---|---|---|
| Persistence | SQLDelight object store, platform SQL adapters, browser SQLite/Wasm/OPFS source, Postgres and Bolt adapters, Cloudflare bindings | Target parity, browser release/migration evidence, portable contracts and adapter conformance |
| Querying and tooling | Provider-specific bounded Data inspectors and typed receipts | Portable query planning, general federation/materialization and admitted administrative execution |
| Authority | Tenant-bearing auth/session flow and target authority resolution; graph query policy helpers | End-to-end scope enforcement for every store, background command and executor |
| Sync | Snapshot-transfer helper and product-specific record sync | General incremental offline sync, merge policy, causal checkpoint and deletion convergence |
| Delivery and work | Provider/product primitives; CompanyOS Workflow skeleton; legacy Meeseeks facade | Remove Meeseeks; qualify graph-owned WorkStore/Runtime/Scheduler, direct platform adapters, Queue/Workflow/PubSub handoff and durable effect recovery |
| Lifecycle | Provider capabilities and product-specific retention/deletion paths | Whole-dataset archive/restore/erase planning and coverage evidence across derived copies |
Source present, test passed, deployed, and qualified are different statuses. Preserve the target, revision, environment, authority, time and test/run receipt for each assertion. September connection tests in the inspector chapter are dated evidence, not a guarantee about today's permissions or production health.
Delivery sequence
- Inventory authority and identity. For one real dataset, name logical entity/schema/operation IDs, tenant/application scope, authoritative records, payload residence, derivatives, owners and provider bindings. Describe legal reads/writes, required consistency and lifecycle. Do not make every provider adopt one physical schema.
- Qualify one complete vertical path. A local app mutation reaches its authority, yields a durable revision/receipt, and returns to the app. Preserve existing bytes and unreadable objects; make account switching and migration explicit. Product sync may remain product-owned during this step.
- Add durable effects. Commit intent, relay it, consume idempotently and show the applied position. Implement the Queue/Workflow profile at a real notification, media or export boundary. Qualify recovery before generalizing adapters.
- Define sync and derived representations. Pin source snapshots or consistency-domain positions, handle gaps/epochs, rebuild indexes, exercise conflicting offline changes and prevent deleted objects from returning. Validate requested semantics before accepting a binding.
- Add lifecycle plans. Enumerate record stores, R2 payloads, indexes, caches, local copies, connector exports, pending work, workflow checkpoints and backups. Return scoped coverage and unresolved obligations rather than a global success flag.
- Extend placement and planning. Introduce another provider or executor only with equivalent or explicitly weakened semantics. Make capability mismatches and movement costs inspectable. Qualify each migration with restore/reconciliation evidence before changing authority.
Acceptance matrix
| Gate | Required evidence |
|---|---|
| Semantic identity | Deterministic descriptor/patch round trips; schema and operation revision changes; no connections opened by definition inspection |
| Service protocols | Typed invocation and schema mismatch rejection; cancellation/unknown outcomes; bounded streams/duplex/upload and publication/job contracts; separate local, HTTP and FFI target conformance |
| Storage and migration | Crash/reopen durability, transactional failure, decoder incompatibility, byte-preserving migration, quota/error reporting and rollback/restore path |
| Tenant and account boundaries | Cross-tenant/adversarial queries, account-switch cache reset, background authority expiry/revocation, target-bound access and redacted receipts |
| Atomic admission | Fault between state change and publish; no lost durable intent; explicit protocol where one transaction cannot cover both records |
| Duplicate effects | Concurrent duplicate commands, same-key/different-input conflict, external ambiguous outcomes and dedup beyond permitted redrive horizons |
| Projection correctness | Missing/reordered events, rebuild, epoch change and source-position checks; accepted write distinguished from applied projection |
| Offline convergence | Divergent edits, stale delete/tombstone, reconnect/replay, schema upgrade and bounded operation-log recovery |
| Workflow recovery | Hibernation, retry after external commit, lost start response, waits/timeouts, invalid gate events, termination and compensations |
| Lifecycle | Export correctness, restore rehearsal, failed partial erase, pending-job fencing, derived-copy deletion, backup retention and late reconnect |
| Portability and scale | Required capability/isolation comparisons, native query/schema compatibility, migration cutover/rollback, partition epoch/fencing, measured load/failover and restore evidence |
| Operator tools | Bounded native reads, catalog/RLS scope, no arbitrary untrusted SQL admission, credential handling and authenticated end-to-end journey |
Use the selected target's actual database and provider profile. A mock broker demonstrates policy logic, not provider recovery or device persistence. Device checks run on physical devices under the repository's development-machine rules; documentation work does not require starting emulators.
Lifecycle as a data contract
Each dataset declares retention, export, backup, restore, archive, encryption and erasure policy. Record authority and payload location can differ: deleting a Memgraph or SQL record does not delete an R2 object, connector document, search index or pending job. A lifecycle plan follows typed ownership/derivation relations and reports its coverage.
Deleting authority creates a revisioned deletion/fencing condition. Consumers and Workflows recheck it before producing outputs; older attempts cannot recreate content after erasure. Retained checkpoint state, DLQ payloads, receipts and legacy browser databases are copies subject to policy. Encrypted payloads, key destruction and permitted backup retention need explicit handling; a log line saying “deleted” is not evidence that every copy was addressed. Tidemark lifecycle owns the detailed architecture.
Preprint coverage
The supplied technical preprint, Reaktor: An Extensible Engine for Applications and Distributed Systems (16 September 2026), especially §§18–19, is an architectural source. Its proposals are not runtime qualification. The following coverage is now explicit in the data chapters:
| Preprint concern | Canonical documentation |
|---|---|
| Data topology, product records and runtime observations as distinct representations | Data graph representations |
| Executable connections, semantic relations and local facets | Graph vocabulary |
| Normative, descriptive, domain and observational facts with provenance and coverage | Identity and evidence |
| Logical identity separate from provider IDs and physical placement | Data graph identity, storage status |
| Authority, sync/merge policy, replicas and derived data | Consistency, sync |
| Source positions rather than timestamps as projection proof | Workflow evidence, graph evidence |
| Transform/work definitions distinct from runs, snapshots and checkpoints | Queues and Workflows |
| Bounded contextual inspection and controlled execution | Data inspection, acceptance matrix |
Lineage can interoperate with W3C PROV and OpenLineage where useful. These are vocabulary/interop choices, not mandatory additional services. Keep graph metadata bounded and permission-scoped; page product records and observations through their stores instead of copying all rows and traces into the registry.
Document ownership and retirement
| Document | Role |
|---|---|
| Tidemark | Architecture, reading map, store families, queries, consistency, sync and lifecycle |
| Data graph | Semantic data vocabulary, identity and evidence |
| Current storage | Implemented API/source boundaries and browser migration |
| Multitenancy | Scope, isolation, fairness, residency and tenant lifecycle |
| Transactions and derived state | Caches, ledgers, state transitions, outbox, sagas and projections |
| Bus, Mesh | Durable transport versus live sessions |
| Queues and Workflows, Work | Cloud execution profile versus local scheduler status |
| Data inspection | Provider browsing, SQL authority and query receipt limits |
| BestBuds schema hardening | Dated application schema evidence and migration design; requires revalidation |
The old private reaktor-data-plan was explicitly superseded on 11 September. It is deleted: its universal journal/DO/rebase architecture, fixed staffing schedule and old API promises are not the current plan. Useful migration, fault and convergence obligations are retained in the gates above.
The older private data-model-audit is also deleted. Its Supabase-managed identity model and live-schema predictions predate the Heimdall migration. Use the schema-hardening chapter and a fresh schema/permission audit; removing the old page does not assert that every historical finding was fixed.
Server and Workbench chapters retain links at their old section anchors, while data-specific content now lives here. The private data access posture, Work roadmap and user-data protection plan remain grouped under the private data section. Public navigation and generated indexes must not expose private content. Related Service, auth, graph-kernel, Operations and product design documents keep their own ownership and are linked from the main reading map.