--- title: "Standard, Permissive, and Lightspeed integrity modes" description: "Choose user-connection, live-replication, and local-image integrity policy independently on each SQLStyle node." section: "Architecture" source_url: "https://sqlstyle.com/docs/lightspeed" --- # 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: ```text 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: ```json5 { "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: ```sql 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.