SECTION 01
Snapshot the exact attempt at creation
A session stores question revision, randomized option presentation, teaching metadata, correct key, domain, position, and pretest status before the first answer.
Session creation first selects the current published release and eligible question revisions. Inside one transaction it inserts the practice-session row and every ordered session item. Each item stores a JSON snapshot containing the stem, randomized options with stable display labels, lesson and concept references, difficulty, explanation, and sources. Separate columns retain question ID, revision, correct option, domain, and whether the item is unscored.
Later catalogue edits cannot rewrite that attempt because grading and review read the session item rather than resolving the current question anew. This protects reproducibility across release publication: a learner sees the same wording, option mapping, explanation, and source metadata when revisiting completed results. It also lets an archived release remain meaningful without requiring every past session to join back to mutable authoring tables.
- Published question revision
Full authored item and source metadata.
- Session item snapshot
Frozen wording, option order, key, explanation, and pretest flag.
- Active learner payload
Stem, option IDs/text/display labels, and difficulty.
- Permitted feedback
Key, rationales, explanation, and sources after policy allows.
SECTION 02
State the key boundary precisely
Learner-session APIs withhold keys until grading; that is not a system-wide claim that no trusted-LAN endpoint can access authoring answers.
The active session serializer constructs a public snapshot with only stem, option ID, option text, display label, and difficulty. Practice feedback adds correctness, the persisted selection, the key, all rationales, the explanation, sources, concept title, and lesson link after submission. Simulation submission returns only saved status. While a session is still active, its results endpoint returns no review items.
The accurate security statement is limited: learner-session APIs withhold keys until grading. The trusted-LAN admin workspace can retrieve draft question records that include correctOptionId so editors can do their job, and the current deployment has no user authentication. The portal must not be described as making answer keys globally inaccessible. The boundary protects the ordinary learner flow under the intended LAN operating model; it is not a substitute for authorization on an untrusted network.
SECTION 03
Define answer and finish races transactionally
Row locks serialize response and completion operations, while practice and simulation intentionally implement different editing policies.
Saving a response joins the session item to its owning session and locks the session row. The handler rejects a missing item, a completed session, an expired simulation, or an option ID absent from the frozen snapshot. Practice inserts with an on-conflict do-nothing policy, then reads the persisted response; repeated clicks cannot replace the first answer after immediate feedback. Simulation uses an upsert because navigation and review require answer changes before final submission.
Finishing locks the same session row. It computes correctness for stored simulation responses, excludes pretest items with a filtered aggregate, writes earned and possible points, marks completion, and then returns the result view. A repeated finish sees completed status and returns the existing result. Because response saving and finishing contend on the session lock, a late write cannot silently cross a concurrently committed completion boundary.
| Property | Practice | Simulation |
|---|---|---|
| Feedback | Immediate after persisted first answer | Deferred until finish |
| Answer edit | No replacement after insert | Upsert while active |
| Correct column before finish | Boolean | Null |
| Passing logic | 80% study target in results UI | Integer earned ≥ stored 92 threshold |
SECTION 04
Call it snapshot-enforced immutability
The application freezes session content and rejects post-completion writes, but the schema is not an append-only ledger protected by database triggers or restricted database roles.
Session immutability is enforced by the application flow and frozen snapshots. The database schema supplies primary keys, foreign keys, and uniqueness for item positions and responses, but it does not install a trigger that forbids session-item updates or an append-only permission model. A privileged database operator or future server bug could mutate a row. Describing the current property as cryptographic, append-only, or tamper-proof would be unsupported.
This distinction guides future hardening. If attempts become regulated records, add database constraints or triggers for completed sessions, separate authoring and runtime database roles, immutable audit storage, and integrity verification. For the current independent learner portal, snapshot-based reproducibility plus transactional status checks is a strong and testable application invariant—as long as documentation names the layer that enforces it.
REFERENCES
Sources and further reading
- Server and Client ComponentsNext.js
Framework reference for keeping data access on the server while isolating interactive browser code behind explicit client boundaries.
- TransactionsPostgreSQL Global Development Group
Database reference for all-or-nothing release changes, session creation, grading, and auditable state transitions.
- Series 65 Exam Study GuideNorth American Securities Administrators Association
Official candidate guidance used to distinguish the real examination from this portal's original instructional material and mock mechanics.
KEEP EXPLORING