MINISTRY RECORDS CONTROL

DATA & PRIVACY NOTICE

The Hidden Files · Official Release v2.0.0

Account continuity and local cache

Your authenticated account continues one fictional employee identity, story progress, reports, qualifications, relationships, department indicators, decision history, operational rotations, settings, and work history. When you sign in, the portal validates and reconciles the account record with this browser's private local cache. While you work, validated changes are synchronized automatically.

The portal does not present separate progression save, load, archive download, archive import, or restore controls. Browser local storage is an offline cache so the same employee can continue during a temporary connection loss; it is not a public profile or a second account. A device cache by itself does not prove account ownership or First Authority. It keeps only an opaque account binding plus the last verified record checksum and server revision to prevent cross-account or stale writes. Signing out removes the current device's private employee cache, recovery checkpoint, continuity metadata, and optional credential portrait; account deletion performs the same device cleanup.

Ordinary Ministry service

One deterministic ordinary-service scene may occupy the employee's existing London-date duty. It creates no second workday, imposes no missed-day penalty, makes no new network request, and creates no cross-account record. Shared public events are read-only context; private employee records and individual ballot choices remain excluded.

Public Alpha 30 derives a bounded Career Evidence Board only from this employee's verified, sealed work record. A deliberate pathway can record a narrowly authorised career effect when its published conditions are met. There is no automatic promotion or discipline. Missed logins, approved leave, and dates without a sealed duty create no adverse evidence. The First Authority receives a separate constitutional service disposition with no superior board and no access to another employee's private account or individual secret ballot.

Public Alpha 31 adds a read-only Living Ministry Service Cycle derived from the current employee's verified sealed career evidence, the current authorised London event, the established service rota, and that employee's own professional relationship summaries. Ordinary employees see only the verified assigned-department programme; a freshly authenticated First Authority receives direct institutional reports across all seven departments with no superior, board, or supervising institution. The First Authority's Senior Auror commission, Special Investigations Division standing, and Level V clearance remain substantively protected. Opening, revisiting, changing locale, going offline, or missing a London date creates no record or network write, no backfill, absence inference, relationship loss, or penalty. The projection cannot automatically change authority, rank, clearance, posting, promotion, transfer, or discipline. Private employee records, other accounts, and individual secret ballots remain excluded.

Public Alpha 32 adds no new employee progression record. Hosted saves use a server-owned monotonic revision: this browser may create only an absent account record or update the exact revision it last read. A stale second device receives a conflict and must reconcile before it can continue; authenticated browsers cannot write the save table directly or choose a timestamp or next revision.

Return-to-Office Handover

Public Alpha 28 presents a read-only handover from facts already authorised for the current account. It separately renders that employee's last fully sealed Ministry Life Continuity record, up to twenty current-account Owl Mail handover items inside the inclusive current seven-date window, the current verified notice, and up to five current verified events. Department, case, staff, and colleague records are not rendered as handover content.

Unavailable or invalid continuity or mail closes the dossier. Stale or mismatched shared-world content is withheld as unverified without closing an otherwise valid dossier. Missing or mismatched staff context disables only the Staff Network preview. The sealed-shift interval does not establish attendance, absence, misconduct, delay, relationship loss, an ignored letter, or an unrecorded outcome.

Opening, closing, revisiting, or using any of the five read-only previews creates no employee, progression, or account-continuity mutation. The previews remain inside the dossier and do not navigate to or initialise existing portal routes; those routes may initialise their own authorised work and are outside the Alpha 28 read-only claim.

Locale selection retains the existing locale preference and may navigate to locale assets, but it creates no Alpha 28-specific request or employee, progression, or account-continuity mutation. The dossier adds no storage key, Save Schema, database object, endpoint, authentication change, telemetry, or new network route.

Living relationships and Owl Mail

Public Alpha 26 generates at most one fictional professional liaison letter for each verified London date and keeps the current date plus six prior dates readable. Listing, opening, or missing a letter creates no read marker, relationship record, penalty, attendance inference, or case progression.

An authenticated employee may deliberately record one immutable reply emphasis for the current date. The bounded account record contains only employee, date, liaison, department, letter, roster and reply identifiers plus a record time. It may safely refer to that account's earlier professional department or meeting decisions, but cannot read another employee's private record or ballot and cannot change rank, clearance, posting, case progress, Service Points, or shared-world state.

Public Alpha 27 projects three-beat, project-original colleague threads from those immutable replies. Completed threads expose only a derived professional working practice. Staff Network progress, letter listing, opening, rereading and locale changes are read-only; missed dates create no backfill, absence inference, relationship loss or penalty. Thread progress grants no rank, clearance, posting, qualification, case access, institutional authority or shared-world change.

Living staff network

Public Alpha 25 displays a deterministic fictional London-date work, meeting and approved-leave rhythm for seven named department liaisons. It does not read any real person's calendar, location, attendance, health or employment record. Opening or rendering the staff desk creates no record.

An assigned liaison employee, or the authenticated First Authority acting as meeting chair, may store one bounded professional emphasis for the day's paired meeting. The record contains employee, London-date, meeting, roster, two department and emphasis identifiers plus a record time. It is capped at 120 entries and follows the existing automatic account snapshot path. It does not contain another employee's private record or secret ballot and cannot change rank, clearance, posting, case progress or shared-world state.

Optional employee credential portrait

The collectible fictional employee credential is complete without a photograph. If you choose a JPEG, PNG, or WebP photograph, the default private route crops, tones, downsizes, and re-encodes it entirely on this device. That canvas step removes the original file name and image metadata. The portal keeps only the treated result in this browser's IndexedDB; it is excluded from local storage, account snapshots, recovery checkpoints, diagnostics, and account synchronization. You can remove it from the credential studio at any time.

The original file is held only in working memory while the browser creates that treated copy. Adding, changing, declining, or removing a photograph never affects House, wand, Patronus, personality, ancestry, employment, clearance, promotion, discipline, or eligibility. The portal does not use facial recognition or infer personal traits from a photograph.

An optional AI styling route is prepared but remains locked by default. It can be enabled only after sign-in, explicit per-request consent, and a production privacy test confirms the protected function's invocation logs do not retain image bodies. When enabled, the portal sends only an EXIF-free reduced portrait copy through the protected function; it does not send the employee name, IDs, magical record, answers, or scores. OpenAI states that API data is not used to train models by default, but abuse-monitoring logs may retain API content for up to 30 days, subject to its safety and legal rules. The portal therefore does not promise immediate deletion by every processor.

Maintainer references: OpenAI API data controls and Supabase Function logging.

Private character resonance

During a new fictional character application, you may optionally enter a date of birth and, if known, a birth time. Those exact entries are used once in browser memory to derive broad fictional resonance signals. The portal does not write the date or time to local storage, recovery checkpoints, account snapshots, diagnostics, or the Ministry Network. An unknown birth time is accepted, and leaving both fields blank has no penalty. Place of birth is not used for resonance scoring; a separately authored personnel biography may still contain it as an ordinary fictional record.

While an intake scene is unfinished, the portal may keep the minimum step state needed to continue that scene on this device. That temporary state is excluded from recovery checkpoints, account snapshots, and the Ministry Network, and is removed when the relevant result or personnel record is sealed. The completed record retains only aggregated fictional signal weights and sealed outcomes, never the prompt-by-prompt choice numbers or the wording of your answers.

The portal does not score typing speed, cursor movement, device sensors, browser history, or activity outside the choices you deliberately select.

The resonance model is a private character-authoring device. It is not astrology, a diagnosis, a psychological test, a factual prediction, or an official Ministry assessment. In the story, the Sorting Hat remains the authority for the original school House, the wand chooses its witch or wizard, and a Patronus form is recorded only after a successful witnessed casting.

Living Ministry Day chronicle

On an attended London work date, the portal can keep one bounded local record of the witnessed magical procedure you performed, the method you chose, its evidence trace and practical consequence, and any duty or colleague outcome already sealed for that date. The record is used to present your shift chronicle and recent practical pattern on this device. It does not infer missed dates, impose an absence penalty, award Service Points, or change identity, rank, clearance, or magical records.

This additive Ministry Day history remains in this browser's local cache with a logical ceiling of 400 dated records and a separate snapshot-size budget. Public Alpha 24 gives it no separate network endpoint. It follows the existing Save Schema Version 5 account-record path during automatic continuity rather than being sent independently.

Seven-department operations

Opening or moving between department files does not create a record. When an authenticated employee deliberately seals a department decision, the portal can retain the employee number, London date, department and docket identifiers, chosen operational approach, resulting government indicators, liaison history, decision time, and the code of any public daily event that supplied context. The record supports the next dated consequence and does not change identity, House, wand, Patronus, rank, clearance, posting, or constitutional office.

Each employee can seal at most one decision for a department on a London date. Department-operation history is bounded to 420 dated records and follows the existing Save Schema Version 5 account path; Public Alpha 24 adds no separate network endpoint for it. The authenticated First Authority remit opens all seven current institutional files, while an ordinary employee receives the file for their assigned department. That access never exposes another employee's private account record or an individual's secret ballot, and liaison history never becomes an access requirement.

Department casework and liaison rota

Public Alpha 24 adds one four-stage continuing case for each of the seven principal departments. Opening a case, checking the portfolio, or reading the London-date liaison rota does not create a record. A record is added only when the authenticated employee deliberately seals one stage choice. It contains bounded identifiers for that employee, case, department, partner office, stage, choice, London date, roster fingerprint, handover route, and record time. Authored case text is not duplicated into the account record.

The rota is deterministic project fiction calculated from the verified London date. It does not read a real person's calendar, employment file, location, attendance, health, or leave record. Its fictional shifts, meetings and approved leave never grant access, impose an absence penalty, or alter another account. Casework is bounded to 28 records and follows the existing Save Schema Version 5 automatic account path; Public Alpha 24 adds no table, endpoint or cross-account contribution record.

Continuing office threads

After a complete attended shift is sealed, the portal may add one deterministic stage to a continuing operational thread. That bounded record can include the fictional office file, London date, witnessed method, authored aftermath, assigned liaison, department-pressure snapshot, and the public event context that shaped the docket. It does not add another reward, trust change, department change, attendance entry, or disciplinary result.

Continuing-thread records are stored under the existing local employee record with a logical ceiling of 400 employee/date entries and a separate snapshot-size budget. They follow the same Save Schema Version 5 account snapshot, protected recovery, and automatic device-cache clearing. They cannot change employee identity, House, wand, Patronus, rank, clearance, current posting, substantive career, or constitutional office.

Account-record retention

The bounded account snapshot contains permanent fictional story gates, static communication receipts, aggregate career and consequence state, the Day 13 duty evidence, and exact dynamic work/read detail for the current World Day plus the prior 179 days. Older dynamic day-level detail can remain in this browser but is not copied into the account snapshot or a protected recovery payload. This keeps multi-year continuity within the service's storage boundary without deleting local history. Every snapshot is protected by an identity check and integrity checksum; no downloadable progression archive is offered.

Authenticated Ministry Network

The hosted release uses a configured Supabase project for account email, session handling, and the authenticated employee continuity record. On entry, the portal validates the account copy before reconciling it with the local cache; subsequent validated changes synchronize in the background. A different-employee record, invalid checksum, unavailable session, or stale conflicting update fails closed. The portal accepts only a browser-safe publishable key; privileged server keys do not belong in this site.

A signed-in employee may also read the shared Ministry date, operating status, and active daily events. That feed contains no employee account record data and cannot replace the personal World Day. It is not retained as a separate local feed; when a public event shapes a completed continuing office thread, a bounded copy of that public docket context may form part of the sealed employee record described above.

Player elections and Ministry government

When the optional Ministry Network is activated, authenticated players may read the same public government, election schedule, candidate names, manifestos, and active decrees. A candidate explicitly consents before publishing their chosen public name and manifesto.

Each authenticated account may hold one ballot per election and may change it only before polls close. A signed-in voter can read only their own ballot. Candidate totals are released only after voting closes; public results never include voter identity.

Ryu TaeO's First Authority office is permanent. Authority exists only when the same authenticated UUID is both the active First Authority roster record and the claimed private EMP-0471 personnel link. Transfer, revocation, retitling, roster removal, truncation, and deletion of that Auth account are refused, and no Minister, board, supervisor, or reviewing institution sits above it. Government commands require a fresh online composite check and pass through one canonical server procedure. That procedure cannot read account email, another employee's private record, portrait, or individual ballot. Government records are not copied into employee caches, account snapshots, or recovery checkpoints.

First Authority decrees publish only an allowlisted operating status and an explicit 6, 24, 72, or 168-hour term. The shared-world scheduler preserves the active decree until expiry and then restores the ordinary daily notice. Superseded and expired decree history is retained for the documented seven-year audit period without exposing account UUIDs or individual ballots.

Local portal diagnostics

The portal can retain up to twenty technical runtime issue markers on this device. They contain only issue type, same-site script path, line position, and time. They do not contain employee records, account email, credentials, case reports, story text, or full external URLs. Nothing is uploaded automatically. You may download or clear these markers from the account desk. A diagnostic report is not a progression record and cannot be imported into the game.

Recovery and deletion

  • Before automatic account reconciliation applies a validated account copy, the current browser record is kept as one protected internal checkpoint.
  • That checkpoint supports failure-safe reconciliation. It is not a player-facing save slot, load option, archive, or manual restore action.
  • Signing out first attempts the latest exact-revision account update, then announces a cross-tab write fence and removes private employee local storage, session data, the recovery checkpoint, continuity metadata, the optional portrait database, and runtime caches. Every layer is verified; a partial cleanup is reported and the portal stays fail-closed. The public verified website shell and language preference remain for the next explicit sign-in, and the authenticated account record remains on the network. The fence prevents an earlier pending sign-in or delayed write from reopening the later signed-out session.
  • “Delete Network Account” is bound to the current live authenticated account. An established continuity record requires its exact employee number. Only a genuinely unstarted account with no save record may use the separate route requiring an exact match to the current account email; the server independently proves by Auth UUID that no save exists. Any save record or permanent First Authority status blocks that route. The JSON request is limited to 16 KiB, confirmation values are neither logged nor returned, and global refresh-session revocation is requested before permanent account deletion and private-device cleanup.
  • Network-account deletion also clears this device's private employee cache and cannot be undone. The departing account's private group membership and active candidacy are withdrawn. Non-private shared work contributions, investigation history, other voters' sealed ballot rows, and certified aggregate results remain as institutional history. The certified totals come from a voter-identity-free immutable snapshot, so deletion cannot rewrite a result that was already sealed. A non-identifying device quarantine remains across reload until both the private cache and local SDK session are proved clear; clearing this site's storage is the recovery path if automatic cleanup is incomplete. The departing account's own ballot is deleted with its private identity; none of the retained history exposes that account's private employee record or ballot choice. No separate local progression record or manual restore control remains afterward.