---
type: decision
tags: [parking, decisions, open]
sources: [parking-system-architecture]
updated: 2026-06-15
status: open
---

# Open Questions / Next Steps

**Not yet decided**, and they drive everything else — settle before procurement. (See
[[parking-system-architecture]] §10.)

1. **Lane topology.** One host per lane, or one central host driving networked devices in each
   lane? Decides how many controllers, printers, UPSs, and [[sqlite]] instances exist, and the
   failure blast radius. (A single central host is a single point of failure for *all* lanes.)
2. **Failure modes.** Define per direction what happens to barriers on host/power/network loss —
   particularly **fail-open on exit** for egress safety. Currently unaddressed. See
   [[fail-state-safety]].
3. **Payment subsystem.** Manned booth (P2PE terminal + cash drawer) vs unmanned pay station;
   confirm **PCI scope is kept out of the application** via a standalone certified terminal
   (see [[bom]]).
4. **Reconciliation channel.** Even if "offline," establish *some* periodic path (USB, hotspot,
   manager visit) to reconcile the signed log against an external authority — the real anti-fraud
   control. See [[reconciliation]].
5. **Durability / backup.** Backup strategy for the [[sqlite]] database + recovery plan; "sync
   later" currently leaves a disk failure as **total revenue-history loss**. _(Confirmed in-scope
   to design, 2026-06-15.)_ Because the DB is the signed [[append-only-event-chain]], a backup must
   preserve the chain intact (a restored copy must still `verifyChain`); options include SQLite
   WAL/online-backup snapshots to a second disk/USB + the periodic external export that doubles as
   the [[reconciliation]] channel (#4). Encryption at rest already applies ([[disk-os-hardening]]).
   Design TBD.
6. **Secure-element integration.** Confirm [[atecc608]] wiring/usage on the host (event
   signing). The [[esp32-custom-controller]] command-authentication use is **deferred — not
   being implemented for now** (access control is the [[dingtian-relay]] behind
   [[network-isolation]]); revisit only if prevention-grade device auth becomes a requirement.
7. **JWT signing: symmetric vs. asymmetric key.** _(Raised by the commit security review, not the
   source doc.)_ Auth currently uses a symmetric HMAC secret (`@fastify/jwt`, see
   [[local-jwt-auth]]) — the same secret signs *and* verifies, so it must live on every host that
   validates tokens. Consider rotating to an **asymmetric key (RS256 / EdDSA)** so the server
   holds only the **public key** to verify; the private signing key can then live in the
   [[atecc608]] or a key-management step. This mirrors the "store only the public key" property
   already used for [[atecc608]] event signing and the [[challenge-response-auth]] scheme —
   compromising a verifying host yields nothing that can forge a token. Decide before
   multi-host / multi-lane deployment (see #1 lane topology), since that's when shared-secret
   distribution becomes the liability.
8. **Exchange-rate (FX) system.** _(Raised by the [[tariff]] design, 2026-06-15.)_ Currency is
   selectable per tariff version and the money model is FX-ready (`payment` stores currency + a
   reserved `fxRate`), but **no conversion is built**. If multi-currency pricing/charging is ever
   needed, it requires an **offline** rate source (rates can't depend on the network —
   [[offline-first]]), a base currency, and a rounding policy. Deferred; nothing blocks adding it
   later without migrating stored amounts.
9. **Pay-station money corners — receipts & refunds/change.** _(Raised by the scope sweep,
   2026-06-15; deferred until pay-station hardware is chosen.)_ Not yet designed: **receipts / VAT
   invoices** (fiscal receipt with tax number + sequential numbering may be legally required — could
   change what the `payment` event must store) and **refunds / overpayment / change** (cash change,
   "exact change only", a refund as a signed reversal event). Both depend on the unmanned-vs-manned
   payment subsystem (#3) and the note/coin/card acceptor hardware. Revisit at procurement.