Skip to main content
Version: Current

Authority and Offline Semantics

Makronexus separates connectivity from write authority. A server can be reachable but intentionally fenced; Cloud can be reachable but not authoritative for a school-owned domain; WAN can be down while the school ERP continues normally.

The three independent questions​

For every onsite workflow ask:

  1. Can this browser reach the School Server?
  2. Is this School Server authorized to accept this governed write?
  3. Can the School Server currently replicate committed work to Cloud?

Those answers are intentionally not collapsed into one online/offline flag.

Per-school/domain authority​

Authority is stored and evaluated by school and governed domain. The platform uses the registered authority policy rather than assuming that whichever side writes last should win.

School-owned operational areas include mapped families such as Finance, Admissions, HR, Operations, school structure, communications/files, and academic operational/reference routes where policy assigns them to the School Server.

Cloud editable-mode middleware checks the same authority boundary. Appliance replication also verifies that the submitting appliance is the authorized server for the domain.

Fail closed

If a governed route/domain cannot be classified or the active authority cannot be positively established, the safe behavior is to deny the write rather than create an uncontrolled dual-writer condition.

Primary School Server​

A school with School Server authority has one active primary appliance for that authority relationship. A candidate replacement does not become a writer simply because enrollment/bootstrap succeeded.

During replacement:

old primary: authority remains until cutover
candidate: enrolled + synchronized + healthy, but write-fenced
cutover: source fenced/decommissioned → candidate promoted → authority transferred
old server: revoked/retired

The persistent local/hybrid footer exposes authority separately from save and replication state.

Saved to school server​

The browser/device has no queued local mutation waiting to reach the School Server. This says nothing by itself about whether Cloud has received the data.

Writes fenced for replacement​

The local API is intentionally not accepting governed school writes because this appliance is in a replacement/cutover safety state. Reads can remain available while the authority transfer is completed.

Write authority not ready​

Authority could not be positively established/refreshed. The appliance fails closed for governed writes until the control-plane policy is known.

Cloud unavailable / N changes waiting for cloud​

The School Server can still be the correct local authority. Committed local work remains on the school database and will converge when the WAN path returns.

Offline definitions​

WAN offline​

Definition: School Server and LAN are healthy; Makronexus Cloud is temporarily unreachable.

Expected behavior:

  • users continue working against the School Server;
  • authoritative school writes continue locally;
  • committed changes wait for Cloud;
  • local files remain available if present on the appliance;
  • Cloud replication retries/converges later.

This is the primary offline-first promise.

School Server unavailable​

Definition: the browser cannot reach the local API over the LAN.

This is not the same condition as WAN offline. The browser outbox may retain only operations permitted by its security/offline policy; sensitive transactions that require a live School Server must wait for server connectivity.

Do not promise that a laptop disconnected from both Cloud and the School Server can perform every Finance, student, attendance, assessment or sensitive operation.

Local only​

Definition: Cloud replication is intentionally disabled by configuration. The School Server remains the local ERP. This is an operating policy, not an error-recovery shortcut.

Hybrid​

hybrid is still a School Server deployment. It receives the local shell/footer and appliance lifecycle behavior while retaining the hybrid Cloud capabilities defined by the deployment.

Cloud writes while School Server is authoritative​

Cloud-side UI/API write paths must respect domain authority. If an operational domain is owned by the School Server, Cloud must not silently create a second writer just because a user has general CRUD permission.

This is especially important for transactional areas such as Finance where conflict repair is not an acceptable substitute for an authority model.

Authority refresh and WAN loss​

The local runtime maintains governed control state so normal WAN loss does not immediately turn into a dual-writer permission bypass. Missing/unresolved authority fails closed. The footer lets operators distinguish authority uncertainty from ordinary Cloud replication loss.

Operator checklist​

  • Cloud fleet identifies the active primary server.
  • Replacement candidates are visibly non-primary before cutover.
  • School-owned domains point at the intended authority.
  • Cloud write attempts are blocked where School Server authority applies.
  • Candidate appliance pushes are rejected before promotion.
  • Local governed writes are blocked when write-fenced.
  • WAN loss leaves primary local operation available.
  • Browser/device loss of School Server connectivity is communicated separately.

Next: Appliance Health and Monitoring.