Skip to content
Merulan

Data, writeback, and schedules

Data, writeback, and schedules keep reads, requested changes, and report delivery under separate checks in an experience.

Data, writeback, and schedules govern what an experience reads, changes, and sends in Apps & Dashboards. A view can load while a write fails. A saved report can exist before delivery succeeds.

Ownership

Data stays with the service that owns it. An App resolves resource handles before asking that service for a read. A Dashboard saves queries separately from the layout that displays their results.

A Dashboard action binds a declared intent to an installed Action and its expected version. The guest cannot choose a different Action. The Company Schema owns what that Action means. Governance & Administration owns access and writeback policy.

Lifecycle

A schedule names the Dashboard, export target, cadence, time zone, recipient, and failure policy. Its saved version must reach the scheduler to govern later sends. Each occurrence rereads that version and checks the creator's current rights. A paused or replaced schedule cannot authorize an old firing.

Writeback has a separate result. An external service can accept a change before its final value is read back. The state awaiting_readback means the service accepted the change. The write has yet to settle.

Boundaries

Data access does not follow from possession of an App route or Dashboard link. The source still applies its permission checks. A Dashboard action also cannot replace its declared Action with a caller's choice.

A schedule preview checks cadence, export readiness, and channel readiness without sending a report. An exported report is not proof of recipient delivery. A writeback acknowledgement is not proof that an external value has settled.

Failures

A schedule can fail to reach the scheduler or fail when it runs. Those stages have different evidence. A denied creator or recipient blocks the send. A rejected send with no effect can follow the saved failure policy. An indeterminate send keeps its reservation and does not send again.

A writeback failure belongs to the requested change. Republishing the App or refreshing its widget cannot settle an external write or resolve a value conflict.

Recovery

A writeback at awaiting_readback needs an observed external result, not another write. Read the writeback status and use the owning repair path for its state. Keep the request and refusal evidence.

For a schedule failure, read the saved version, last scheduler error, occurrence outcome, and delivery receipt. Recover app delivery explains when to restore access, pause sending, or investigate an uncertain effect.