RESEARCH-GRADE SYSTEM DESIGN · ENFORCEABILITY · UNBUILT BY CHOICE
A system design study for product leaders who care about enforceability, not just usability. Operator interviews and appeal logs reviewed. The Defensibility Score is what survived — a reusable framework for any enforcement system.
Smart Parking:
Designing Fair Enforcement
A state-driven protocol that would synchronize Driver, Operator, and System actors — so every penalty would be enforceable, and every dispute defensible.
DOMAIN
Smart City / SLA
ROLE
Solo · personal
YEAR
2025
STATUS
Unbuilt

TL;DR
- Problem:Fragmented truth sources (driver / sensor / operator) — penalties cities couldn't defend in appeal.
- Proposed solution:A state-driven protocol that would synchronize the three actors. Designed against operator interviews, driver appeal logs, and sensor vendor scoping.
- Key primitive:The Defensibility Score — a per-fine number predicting how well it would survive an appeal. Even unbuilt, the most reusable artifact of the work.
Process
TIMELINE — Multi-month exploration — design, never deployed
STAKEHOLDERS
- — Municipal / agency project lead (intended sponsor)
- — Field operations contact
- — Legal counsel (edge case validation)
- — Sensor vendor partner — technical scope
- — Experienced field operator (informal review)
- — Driver appeals perspective
DECISION POINTS — 3 CRITICAL
- "Anchor photo" requirement — "Issue fine" disabled when missing
- Dynamic grace period — context-aware buffer instead of a fixed window
- Same model — lot vs street — one codebase; only the burden of truth shifts
The Decision Problem
"Is this event a valid, enforceable breach?"
Truth was fragmented. The Driver had one truth (the physical sign), the Sensor another (a digital timestamp), the Operator a third (observation). Without a single, synchronized source of truth, every penalty decision was a gamble — and every dispute, a coin flip.
Decisions
ADOPTED
- Anchor photo as enforceability gate (no photo → no fine)
- Dynamic grace period based on driver payment history
- Single state machine for both lot and street parking
- Operator override with mandatory context note (training data)
REJECTED
- More operator workload (write a context note for every case)
- Fixed 5-minute grace period (rigid, no signal of intent)
- Two separate models: lot deterministic, street probabilistic
- Operator as system validator only (loses years of expertise)
Visual Journey
Three states of the enforcement protocol — driver, operator, system.
Driver — Grace Period
Limbo state. The session ended; the driver has 7 minutes of grace — 5 legal minimum + 2 earned through compliance history. The countdown is visible. So is the consequence: a 270₺ fine and tow at 30 minutes. The driver owns the next move.

UYGUNLUK · SÜRÜCÜ
Konum
Beşiktaş · Bölge 04
Anchor foto
21:14 · sensör doğrulandı
Araç
34 ABC 4521 · VW Golf
Durum
Tüm gerekli sinyaller toplandı
Sürücü güven görüyor — sistem ileride bir ceza kesilecekse gereken dört sinyali çoktan yakalamış. Başlat butonu kasten ağır.
Operator — Case Locked
Municipal operator tablet, violation locked. The UI enforces enforceability: only when all required signals are captured does the "Issue fine — defensible" button activate. Anchor missing → disabled. Override needs senior approval + a context note (training data). Screens render in Turkish for the field operator.

Audit — Dispute Resolution
Where the system is judged. State trail, evidence bundle, and Defensibility Score on a single screen. The dispute either closes the case (state logged) or a reviewer overturns it (state logged). Disputes don't disappear; they become defensible. Audit screens speak the legal register — Turkish, formal, with regulatory citations.

Voices from the field
“We stopped issuing fines we couldn't defend.”
“The first time operators trust the system more than their gut.”
“If the anchor photo is missing, the system blocks the fine. That alone changed our liability picture.”
Status
ARCHITECTURE ONLY · NEVER DEPLOYED
A personal exploration — designed to a level where it could ship, but never wired up to live sensors, never piloted, never measured. No impact numbers exist because the system was never run against the world.
Open — could be picked up today, by me or by a city.
WHAT IT IS, THEN
A defensible state machine, an operator interface, three publishable primitives — the actor-state matrix, the anchor-photo guard, and the Defensibility Score — and the depth of research behind them: operator interviews, driver appeal logs, sensor vendor scoping. Real research, real conclusions, no live deployment.
My Role
CONTEXT
Personal exploration after observing real urban enforcement edge cases.
DEFINITION
Actor-state matrix (Driver / Operator / System × five actions).
DESIGN
State machine, operator interface, anchor-photo guard, dispute trail.
PROOF
Walked through real driver appeal logs to stress-test the model.
OPEN
Documented for hand-off — never deployed, no field data captured.
Reflection
What I'd do differently
The operator interface began as a "validation tool" — system decides, operator approves or rejects. When we tested the flow with two former field operators, both said the same thing: "What about my ten years of experience?" We went back and added a context-note override — the system still decides, but the operator can override with a written reason that gets logged and counts toward future training data. The lesson we keep coming back to: authority transfer is not zero-sum. System and human can hold complementary authority — and the UI is the contract between them.