Lightspeed: OFF by default, proof before reuse.

SQLStyle has three integrity modes. Standard starts each managed user connection at synchronous=NORMAL and restricts later changes to NORMAL or FULL. Permissive does not override the database core’s connection default and leaves every supported synchronous value available. The supported Bedrock build defaults to FULL.

Internal live-replication connections use a separate policy: Standard and Permissive replicas apply at NORMAL, while Lightspeed replicas apply at OFF. Standard and Permissive can admit an unproven local image after SQLite recovery while queuing a full snapshot. Lightspeed seals a fully checkpointed clean close with SHA-256; if the required proof cannot be established on restart, SQLStyle recovers from authoritative state or stays fenced.

Compare the three modes

Behavior	Standard	Permissive	Lightspeed
New managed user connection	synchronous=NORMAL	Bedrock default (FULL)	synchronous=OFF
Connection may select later	NORMAL or FULL	Any value supported by the database core	Any value supported by the database core
Live physical or logical replica apply	synchronous=NORMAL	synchronous=NORMAL	synchronous=OFF
Live concurrent WAL checkpoint	synchronous=NORMAL	synchronous=NORMAL	synchronous=OFF
Unknown local integrity after an enrolled Standard or Permissive cycle	Admit after SQLite recovery and refresh a full snapshot asynchronously	Admit after SQLite recovery and refresh a full snapshot asynchronously	Recover from authoritative state or remain fenced
Unknown local integrity after an enrolled Lightspeed cycle	Recover from authoritative state or remain fenced	Recover from authoritative state or remain fenced	Recover from authoritative state or remain fenced
Matching clean-close SHA-256	Admit and allow the requested mode	Admit and allow the requested mode	Admit and allow the requested mode
Commit durability	SQLite NORMAL or FULL semantics selected by the connection	Depends on the value selected by that connection	Depends on the value selected by that connection

The mode defines user-connection initialization and restrictions, internal live-replication and concurrent-checkpoint synchronization, and local-image admission. It is not a database-wide lock on PRAGMA synchronous. A user connection may change its own setting within the selected policy, and that change does not alter the database’s integrity mode, internal replica applier, or live checkpoint worker. SQLStyle’s terminal maintenance and lifecycle-metadata connections use FULL when establishing durable evidence.

Permissive removes the synchronous guardrail

Permissive is useful when an application needs the database core’s native connection default and the freedom to choose any supported synchronous value. The Bedrock build currently starts those connections at FULL; Permissive itself issues no initialization PRAGMA. The available later values include OFF and EXTRA.

It also changes the failure envelope. If a Permissive connection selects OFF, returns commits, and then ends without a valid clean seal, a later Standard or Permissive cycle may admit that dirty local image after SQLite recovery and queue a full snapshot. Recent OFF commits may be missing after a host failure. Choose Permissive only when that combination is acceptable; choose Lightspeed when an unproven enrolled image must be recovered or fenced.

The clean-close seal

Before application or internal database writes begin, SQLStyle records a dirty cycle and its actual mode with FULL synchronization. A graceful terminal shutdown then fences new opens and writes, drains processes and capture work, forces a truncating checkpoint on a FULL maintenance connection, closes handles, syncs the main file and directory, and verifies that rollback, WAL, and WAL2 shared-memory files are absent or empty.

Only then does SQLStyle hash the complete main database file with SHA-256 and commit the clean record. Failure before that final record leaves the cycle dirty. Header inspection and quick_check are not substitutes for this seal. quick_check may still validate a backup artifact, but it does not prove that an enrolled image is safe to reuse under the configured policy.

On restart, a matching clean seal allows every transition among Standard, Permissive, and Lightspeed. Unknown proof after a Standard or Permissive cycle can be admitted under either of those modes while a full snapshot refreshes in the background. Requesting Lightspeed requires authoritative recovery. Unknown proof after a Lightspeed cycle requires recovery regardless of the newly requested mode. A looser connection policy cannot erase stricter provenance.

First enrollment is a trust anchor

A database with no lifecycle ledger is being enrolled for the first time. SQLStyle explicitly trusts that image, records the requested cycle as dirty, and admits it in any mode after authority and frontier checks. If the database is nonempty, SQLStyle queues an exact transaction-consistent full snapshot. Standard and Permissive admission do not wait for that upload; failures remain observable and retryable.

By default, the ledger is stored in a runtime database beside the main database. For data/app.sqlite3, the path is:

data/app.runtime.sqlstyle

runtime.path can set another location. Deleting the runtime database resets the trust anchor. That is an explicit operator decision, not a repair technique. An existing malformed, version-1, or otherwise unsupported ledger fails clearly and is never treated as a new enrollment.

Agreement is local to one database image

The active runtime owner publishes the integrity mode in shared memory. Another process may attach with a different requested mode, but its open connections follow the active owner’s coherent policy. Its successfully normalized setting becomes the desired policy if that process later starts the next owner generation. Terminal cleanup reads the durable integrity ledger rather than treating shared memory as durable identity.

Replication does not extend that agreement across nodes. Each replica advertises its configured mode, the primary replies with its own, and all nine Standard, Permissive, and Lightspeed pairs can stream physical or logical data and perform replacement. Each node keeps its local user-connection, apply, and image-admission policy, so you can change modes as a rolling node-local configuration update. Promotion does not copy or change another node’s mode.

When a Lightspeed primary streams to a Standard or Permissive replica, SQLStyle logs one warning for that physical or logical stream. The primary can return OFF commits faster than the replica’s NORMAL applier can make them durable, so a busy primary may outpace the replica. SQLStyle does not inspect user connections when making this observation.

A validated live shared memory may support same-boot process takeover. If that evidence cannot be reused, cold-start ledger rules apply.

Configure and inspect the mode

integrity_mode is an inheritable database setting:

{
  "version": 1,
  "defaults": { "integrity_mode": "standard" },
  "databases": {
    "app/main": {
      "path": "data/app.sqlite3",
      "integrity_mode": "permissive"
    }
  }
}

The default is standard. Unmanaged databases accept the setting for configuration parity but ignore it. Inspect the active mode through the same managed connection:

SELECT authority, lifecycle, integrity_mode
FROM sqlstyle_status;

Integrity is not durability or freshness

The SHA-256 seal proves byte identity for one cleanly closed local image. It does not prove that the image contains the latest cluster transaction. SQLStyle still reconciles authority, lineage, and transaction frontiers before admission.

Likewise, Lightspeed and Permissive do not make synchronous=OFF commits power-loss durable. Recent OFF commits may be lost after host failure. Replicas and object storage can provide recovery sources, but a returned commit does not automatically wait for either one. Lightspeed’s promise is narrower: SQLStyle will not blindly reuse an enrolled local image whose required clean byte seal cannot be proven.