Furries PH Docs
Dashboard
EMS LAN docs

Reference

File Formats and Schema

EMS LAN snapshot formats, schema version, exported timestamp, source metadata, and signing concepts.

AudienceSupport leads, Import operators
Dashboard surfaces/rego/events/manage/offline-snapshot?id=:eventId
Records touchedSnapshot files, Snapshot schema

Use This Reference Carefully

Use this guide when event work may happen on local devices, offline files, or LAN-only tools instead of the live online dashboard. In this guide, File Formats and Schema narrows that work to eMS LAN snapshot formats, schema version, exported timestamp, source metadata, and signing concepts. Because this is a reference page, read it as part of the EMS LAN learning path rather than as an isolated checklist.

EMS LAN keeps an event moving when internet access is unreliable, but it also creates a second place where event records can change. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What This Reference Collects

This page is for checking details. Use it to confirm names, routes, records, fields, or certification points before relying on memory. The intended readers are Support leads and Import operators. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

  • Primary surface or service: /rego/events/manage/offline-snapshot?id=:eventId.
  • Records or contracts involved: Snapshot files and Snapshot schema.
  • Main care point: Watch for losing track of which file, device, person, or import is trusted while attendee, staff, inventory, POS, or check-in records change offline.
  • Proof worth keeping: event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note.

How To Find The Right Entry

  1. Search for the exact name or route: Begin by naming the EMS LAN situation, the owner, and the exact item involved in File Formats and Schema.
  2. Read the surrounding note, not only the matching line: Use /rego/events/manage/offline-snapshot?id=:eventId to connect the words on the page to the screen, file, service route, or record that people actually use.
  3. Compare the reference with the live screen, file, or service evidence: Keep Snapshot files and Snapshot schema in view so the work stays tied to the records or contracts it can affect.
  4. Save the evidence that proves the entry was checked: Before handing off, save proof such as event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note so the next lead can tell which file and device state are trusted.

Confirm The Reference Still Matches Reality

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

  1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
  2. Impact is understood: The operator can explain the effect on offline files, check-in access, staff rosters, inventory counts, POS totals, and import history.
  3. Proof is findable: The handoff points to evidence that the next lead can tell which file and device state are trusted.

End-to-end operator runbook

Use this numbered runbook when checking a file-format question.

  1. Step 1 - Identify the thing being verified. Identify the filename, event ID, format, and export timestamp. This tells you which file is being reviewed.
  2. Step 2 - Translate the technical name into plain language. Check whether the file is ZIP, GZIP JSON, JSON, or .fphlan. This determines expected import handling.
  3. Step 3 - Match the route, file, or record to real workflow. Compare the file to expected schema version, source metadata, and signing behavior. This checks whether the file is plausible.
  4. Step 4 - Collect enough evidence to avoid guessing. Treat missing event ID, old timestamp, wrong schema, or signing failure as a stop condition. This prevents unsafe import.
  5. Step 5 - Confirm implementation and docs agree. Record the file decision in import or failure notes. This gives support leads context.
  6. Step 6 - Send the result to the right owner. Return to import, failed import, or reconciliation after the format question is answered. This keeps the workflow moving.

Formats

FormatRole
.zipStandard LAN app export and import package.
.json.gzCompressed JSON export for technical workflows.
.jsonJSON snapshot content where accepted.
.fphlanLAN-specific snapshot package accepted by import.

Required metadata

  • Snapshot schema version.
  • Snapshot exported timestamp.
  • Snapshot source metadata.
  • Event ID.
  • Change summary after import.
  • Actor and audit fields in sync history.

All docs