System Design · Authority · Enforceability

Enforceable State:
Designing Authority

DOMAIN

Smart City / SLA

FOCUS

System Design

STATUS

Design Exploration

Context: Physical asset management is defined by signal divergence. The Driver observes physical reality (signs), the Sensor records digital reality (logs), and the Operator interprets context. When these signals conflict, enforcement becomes a liability risk.

TL;DR

  • Problem: Fragmented truth sources led to unenforceable penalties.
  • Solution: A state-driven protocol that synchronizes Driver, Operator, and System Actors.
  • Key Insight: You cannot fix downstream disputes with dashboards; you must fix the upstream capture of state.

The Decision Problem

“Is this event a valid, enforceable breach?”

The "Truth" was fragmented. The Driver had one truth (physical sign), the Sensor had another (digital timestamp), and the Operator had a third (observation). Without a single, synchronized source of truth, every penalty decision was a gamble.

Action
Driver
Operator
System
Start parking session
Query status
Establish ruleset
Issue enforcement
Manual override
(LOG)
Resolve dispute
System of record

FIG 01: System > Operator > Driver

System Actors

1. The Driver

Owns "Physical Reality".

2. The Operator

Owns "Contextual Observation".

3. The System

Owns "Legal Reality".

Hierarchy of Truth

To resolve ambiguity, we established a hard-coded hierarchy of evidence.

Physical Infrastructure

Signpost

Highest Authority

Payment Log

Receipt

System Truth

Sensor Event

Camera

Trigger

Observations

Human Eye

Context only

System Mechanics

The enforcement logic is built on a finite state machine. An asset cannot move from "Valid" to "Violation" without passing through a "Grace" state.

Decision: The "Grace" State

REJECTED ALTERNATIVE

Instant Enforcement

Too rigid. Creates a "predatory" perception and increases "I was just paying" disputes by 400%.

CHOSEN DIRECTION

Deterministic Buffer

Legal buffer is encoded. If payment arrives in this window, the violation self-corrects.

STATE 01 Valid Legal
STATE 02 Grace Buffer
STATE 03 Candidate Potential
STATE 04 Confirmed Evidence
STATE 05 Enforced Immutable

Parking Session as a State Machine

STATE 01

Eligibility Check

Is this vehicle subject to rules? Diplomats and emergency vehicles are invisible to the engine.

Eligibility Check Mockup

STATE 02

Active Session

Vehicle is liable but compliant. "Do nothing" is the hardest feature to design.

Active Session Mockup

STATE 03

Grace Period

Limbo. Money ran out, but law requires a buffer. Dangerous state where truth is fluid.

Grace Period Mockup

STATE 04

Escalation Ready

Violation locked. Burden of proof shifts to human to gather evidence.

Escalation Ready Mockup

One System, Two Contexts

This project proves that the same core authority model governs both probabilistic (street) and deterministic (lot) environments. The only variable is who holds the "burden of truth".

Lot Parking Diagram

Operator Interface

When the system fails to determine state, the human operator steps in. The UI is designed to validate authority, not just display data.

SCENARIO: "I Didn't See The Sign"

When a driver claims no signage, the Operator Interface enforces a check: "Is the Anchor Photo visible?" If 'No', the enforcement cannot proceed. The UI disables the "Issue Fine" button.

Outcome: The interface protects the city from legally void fines.

Operator Interface

Constraints

Latency is Legal Risk

If the system is 30s slow, a user might pay *after* enforcement starts. Real-time sync is mandatory.

Conflicting Signals

App says "Free", Sign says "Paid". Legal precedent prioritizes physical signage.

WHAT THIS IS

System design exploration.

WHAT THIS IS NOT

Pixel-perfect consumer app.