Data authority, contracts and federation

Technical preprint, 16 September 2026 — web reading edition. This preserves the supplied paper’s content and its historical evidence boundary. Proposed interfaces, conditional propositions and constructed studies are not released APIs or deployment proof. Aligned equations, tables and listings retain their source layout. Source figure pages retain the original vector artwork. The accompanying finite model and coverage-map source package were not supplied; their reported results have not been independently reproduced here.

Current guides: reaktor-db · reaktor-data-graph · reaktor-data-implementation.

The engine and feature composition · Graph model, protocols and computation · Platforms, identity and polyglot execution · Data authority, contracts and federation · Build, compilation and resource budgets · LiveUpdate, coordinator and human-agent authoring · Assurance and adoption studies · Precedents, evaluation and implementation sequence · References, notation, exercises and source lineage

18. The system knowledge graph and data layer

The executable port graph is embedded in a wider typed system model. Three constructs remain distinct. A connection is a binary edge or hyperedge between ports, with executable semantics. A relation is a typed assertion between system entities. A facet is local typed metadata. An authorization policy can protect an operation through a relation without inventing artificial executable ports for policy knowledge. Let 𝑈 be the identity universe containing structural entities and domain entities. An aspect 𝐴𝑖 = (𝑈𝑖 , 𝑅𝑖 , 𝐹𝑖 ) selects or introduces entities, typed relations, and attributes, with explicit references into 𝑈. Auth, navigation, data lineage, deployment, and telemetry aspects can have different node sets. They share identities where they refer to the same entity. Aspects have different meanings. Normative aspects impose requirements. Observational aspects report evidence. Descriptive aspects connect source, ownership, and documentation. Domain aspects describe their own topology. Visibility in a projection does not control enforcement: hiding authorization annotations cannot disable an authorization requirement.

18.2 Assertions, provenance, and completeness

An assertion records its subject, relation or field, object or value, source, source revision, extraction method, authority, valid scope, and freshness information. Evidence classes distinguish declarations, generated facts, static inference, runtime observations, and heuristics. A confidence score is not a permission and is not a calibrated probability unless a separate calibration procedure establishes that interpretation. Provider fragments are merged through declared identity and authority rules. Contradictory claims remain inspectable. A resource can be desired but unobserved, observed but undeclared, divergent, stale, or of unknown status. An absent observation is not proof of nonexistence when the provider query was incomplete or failed. A projection records its scope, filters, exclusions, assumptions, and completeness class. In an imported system, an unobserved call can still exist. Closed-world analyses require a complete boundary or a conservative overapproximation; otherwise the appropriate result is unknown or a scoped finding. The phrase “complete application graph” means coverage relative to explicit boundaries and evidence, not omniscience about arbitrary code.

18.3 Three connected data representations

The system distinguishes a data-topology graph, a product-data graph, and an observation graph. The first contains stores, datasets, schemas, queries, authorities, projections, caches, synchronization, and retention. The second contains application records and relationships, such as people, conversations, or learning concepts. The third contains query executions, projection runs, checkpoints, lag, and failures. A DataDescriptor declares the data contract, authority model, placement constraints, derived projections, synchronization protocol, merge policy, and retention. A source dataset can be authoritative while an on-device mirror, graph projection, and analytical view are derived. The graph records which operations read or write the dataset and which transformations produce each copy. This extends the authority/projection discipline in the Reaktor data-layer design [71, 8]. An authority is a logical consistency rule, not necessarily one physical machine. The default can be server-authoritative product state. Selected collaborative fields can use a declared replicated merge algebra. Combining those approaches requires explicit field or aggregate boundaries; a cache cannot silently become a second authority.

18.4 A concrete data realization

The reference stack gives these abstract roles concrete implementations. The documented local store is an ObjectDatabase/ObjectStore over SQLDelight, with SQLite-based native/JVM realizations and a browser persistence path. Postgres supplies transactional product authority; Worker-side access uses a Hyperdrive-backed adapter, while the JVM uses its database adapter. Memgraph supplies a relationship projection, ClickHouse supplies analytical processing, and R2 supplies object storage. The documentation reports the local and several server adapters separately from the proposed unifying DataDescriptor and synchronization engine [71]. These choices define a reference profile, not a requirement that every application deploy every store. In the photograph example, the local draft has an installation-scoped identity and a pending upload operation. The authoritative message record refers to an accepted media object; the object store contains the bytes, not the authorization decision. A publication can update a conversation projection, a notification workflow, and an analytical aggregate. Their checkpoints explain which authoritative facts they have processed. A missing thumbnail and a stale engagement aggregate are different failures, even when both ultimately concern the same message. A descriptor needs to distinguish payload residence from metadata authority. Declaring that a message is authoritative in Postgres does not imply its image bytes are also stored there. Likewise, a Memgraph

relationship can be authoritative for a deliberately graph-native domain rather than always being a
projection. The owning application declares that choice per dataset or aggregate; a technology name
cannot determine it.
// Proposed descriptor: physical names are bindings, not secrets.
val messages = dataset<Message>("conversation.messages") {
  authority(transactionalStore("product"))
  localMirror("conversation-working-set", scope = Installation)
  objectReferences(mediaStore("attachments"))
  projection("conversation-relationships", checkpointed = true)
  projection("engagement-analytics", checkpointed = true)
  retention(productRetentionPolicy)
}

This declaration describes intended relationships. An adapter must still implement filtered synchro-nization, authorization, retention, and checkpoint reporting before the corresponding capabilities are available. The inspector shows pending local intent, authoritative acknowledgment, and projection progress separately. It does not infer successful application merely because an event was emitted. The schema-hardening report provides a useful implementation-grounded motivation: broad com-patibility views multiplied identity rows and amplified downstream joins, while refresh-token rotation needed database-enforced single-use behavior [72]. A system graph can connect the query, compatibility view, schema revision, and affected operation. Correcting the query or transaction still requires database expertise. The benefit is making that expertise reusable through explicit projection contracts and regression gates rather than hiding it behind a supposedly universal store API.

18.5 Synchronization and consistency evidence

Local optimistic state distinguishes pending intent from acknowledged authoritative state. Upload operations carry stable identities and pass through server-side validation. Synchronization applies source-origin and revision information to avoid interpreting replicated writes as fresh user intent. Read-your-writes requires evidence that the selected replica or local mirror has applied the required commit position or causal frontier. A timestamp, including a hybrid logical clock, is not sufficient by itself. Cross-store queries declare whether independently fresh projections are acceptable or whether a compatible checkpoint is required. A schema change and a projector update must preserve the relevant checkpoint interpretation. Lineage records connect a transformation definition to its executions and datasets. OpenLineage’s distinction between datasets, jobs, and runs is a useful interoperability model [73]. Large product records and telemetry remain in their appropriate stores; the system graph holds typed references and retrieves authorized bounded slices. This prevents the architectural registry from becoming a mandatory in-memory copy of every application datum.

18.6 Cloud resources, tools, and external systems

Cloud providers, infrastructure configuration, source indexes, build tools, tests, and operational APIs contribute typed fragments. An operation provider exposes actions such as inspect, query, test, preview, deploy, or drain. Its contract specifies arguments, outcomes, authorization, target scope, idempotency, and side effects. A tool invocation is related to its declared operation, execution attempt, logs, and artifacts. It is not treated as successful because an agent describes it as successful. Native build receipts and operation results remain attributable evidence. Infrastructure reconciliation compares desired state with provider observations; it is not a direct assignment to the observed graph.

Foreign components can enter through published schemas, wrappers, source analysis, or runtime observation. Importers must not execute arbitrary source initializers just to discover topology without a suitable isolation and authorization model. More precise knowledge can enable more analyses, but mutation authority still comes from an explicitly authorized operation provider, not from knowledge fidelity alone.

18.7 Security boundaries and privacy

Reference capabilities, platform capabilities, and permissions are separate. A reference capability grants access to a supported interface. A platform capability describes what a runtime can implement. A permission describes what a principal may do in a context. Possessing type metadata grants none of them. An authorization requirement is linked to its enforcement points, authenticated context, and protected effects. Enforcement applies to local as well as remote paths. Data-dependent checks remain necessary even when a graph proves the absence of a structural bypass. Information-flow claims require a conservative model of internal transfers and declassification; wiring alone does not establish them. Read access to the system graph is itself governed. Schema, lineage, traces, and source locations can disclose sensitive information. Agent views default to the least required metadata and redacted evidence. Secrets are references to authorized providers, not values included in snapshots. Offline access and immediate revocation are conflicting requirements in some deployments; their chosen policy is represented explicitly.

Original page layout, starting at page 45

19. Federation, data contracts, and operational integration

The executable graph describes the portion of a system under Reaktor’s runtime semantics. The system knowledge model connects that portion to source, data, infrastructure, release artifacts, operations, and evidence. Federation is necessary because those facts have different owners, storage systems, lifetimes, and access policies.

19.1 Facts have authority and provenance

An imported assertion should identify its subject, predicate, value or related entity, authority, source revision, and observation context. Provenance can itself be a graph of entities, activities, and responsible agents, as formalized by the W3C PROV family [74]. The existence of provenance does not establish truth; it makes the origin and derivation of a claim inspectable.

data class SystemAssertion(
  val subject: EntityRef,
  val predicate: RelationTypeId,
  val value: AssertionValue,
  val authority: AuthorityId,
  val sourceRevision: SourceRevision?,
  val validContext: ContextPredicate,
  val evidence: EvidenceRef,
)

interface SystemGraphProvider {
  val descriptor: SourceDescriptor
  suspend fun read(request: FragmentRequest): GraphFragment
  suspend fun changes(after: SourceCursor): ChangePage
}

The registry does not turn competing assertions into one value through unrestricted last-write-wins. A declaration that a queue should exist and an observation that it is absent are consistent statements about

different planes. Conflicting authorities over the same declared fact require an ownership decision or an explicit unresolved conflict. Identity reconciliation also needs evidence. Source symbols, deployment names, and telemetry service names can be aliases for one component, but similar text is not enough. An importer can propose a link; an authority can confirm it. Deletion must leave enough history to distinguish a removed resource from a renamed or temporarily unobserved one.

19.2 Data descriptors connect topology to semantics

A dataset descriptor can name its logical schema, authority policy, representations, derivations, merge rules, retention, and access requirements. An authority can be one server-managed transactional service or a specifically defined replicated data type. “One authority” means one coherent rule for resolving truth, not necessarily one physical process.

data class DataDescriptor(
  val dataset: DatasetId,
  val schema: DescriptorRef,
  val authorityPolicy: AuthorityPolicyRef,
  val representations: List<RepresentationRef>,
  val derivations: List<DerivationRef>,
  val merge: MergePolicyRef?,
  val retention: RetentionPolicyRef,
  val access: AccessPolicyRef,
)

A representation identifies whether it is authoritative, a projection, a cache, or a provisional local state. A derivation identifies inputs, transformation code, output schema, and progress/checkpoint semantics. An analytical projection is not permitted to become an accidental second transactional authority because its query API also allows writes. An applied position should be interpreted by the relevant source and projection protocol. For a single ordered source it may be a log position. For partitioned sources it can be a vector of positions. A Reaktor read requiring its earlier write should bind that write to the projection state actually used for the query. A generic timestamp comparison is insufficient.

19.3 Lineage describes both definitions and runs

The definition of a transformation is distinct from a particular run. A run can fail, retry, process a subset, or use a specific input snapshot. OpenLineage’s separation of jobs, runs, and datasets is a useful interoperability boundary [73]. Reaktor should link those objects to operation identities and code revisions rather than retain only a decorative edge saying “feeds analytics.” For example, a campaign recommendation dataset depends on an engagement source, a projector artifact, a schema revision, and a successfully applied checkpoint. An incident investigation can distinguish a dead consumer from a running consumer that rejects a new schema. The topology explains the path; runtime evidence explains which part of that path progressed. Record-level product graphs remain in their stores. A social graph may contain millions of people and relationships, while the architecture graph contains the schema, queries, services, and access paths over that data. The workbench joins bounded authorized slices when needed. Treating every product record as a permanently loaded architecture node would mix scale, privacy, and lifecycle concerns unnecessarily.

19.4 Builds and releases as derived relationships

A build action consumes declared source and dependency inputs and produces artifacts. Reproducibility improves when those inputs include toolchain versions and relevant environment rather than depending on ambient state. Bazel’s hermeticity documentation gives a practical account of isolation from undeclared host inputs [75]; Nix provides a distinct deployment model organized around explicit derivations [76]. Reaktor need not replace either system. A build-provider interface can connect their actions and artifacts to graph entities. A release then selects compatible artifacts, schemas, deployment plans, and update manifests. A reproducible artifact is not automatically a safe artifact; tests and policy still determine whether the release is acceptable. The dependency graph used for caching must include the actual inputs to an analysis or build. If a compiler plugin, schema registry revision, or protected policy changes, cached results depending on it need invalidation. Negative dependencies matter as well: a query asserting that no extra implementation exists can change when a new implementation is added.

19.5 Operational actions are typed, scoped, and evidenced

A cloud resource can expose an inspect action, a deployment preview, a controlled restart, or a query operation. Each action specifies inputs, authority requirements, effect scope, idempotency/retry behavior, and the form of its receipt.

interface OperationProvider {
  suspend fun describe(target: EntityRef): List<OperationDescriptor>
  suspend fun prepare(command: OperationCommand): OperationPlan
  suspend fun execute(
      plan: OperationPlanRef,
      authority: OperationAuthority,
  ): OperationReceipt
}

A receipt identifies the command, target revision, executor, timestamps, result, logs, and artifact references. It also distinguishes a request accepted by a cloud API from the later observation that the intended resource became healthy. Operation execution does not silently rewrite the declared model to match whatever happened. A native application module has no reason to receive these administrative capabilities. Workbench and deployment runtimes use separate scopes. A source scanner that discovered a legacy service can expose source navigation without automatically gaining permission to redeploy it.

19.6 Federated consistency and bounded materialization

Each provider has its own cursor and refresh semantics. A system query can return a vector of watermarks and identify stale or unavailable sources. Analyses that tolerate eventual consistency can proceed with that evidence; analyses requiring a coordinated cut need a stronger acquisition protocol. There is no globally atomic snapshot merely because a registry assigned the response one identifier. A large installation can partition the registry by project, tenant, authority, or domain, with cached summaries at higher levels. A query requests the relevant subgraph and explicit boundary summaries. Cross-project navigation resolves those summaries on demand. This mirrors the logical principle of open modules: a useful high-level view depends on interfaces and traceability, not on eagerly loading every implementation and observation.

Original page layout, starting at page 48