ParkReply

ParkReply is a privacy-first communication platform for real-world interactions. Its SafeRelay prototype enables purpose-driven, explainable communication while protecting personal identity.

Comment

ParkReply: Privacy-First Communication for Real-World Moments

Most people have experienced a moment when they needed to contact a stranger but had no safe way to do it: a car is blocking a garage, headlights were left on, keys were found, or a passport was handed to reception.

The usual solution is to exchange a phone number, email address, social profile, or home address. That solves a temporary communication problem by creating permanent personal exposure.

ParkReply offers a different model. It creates a trusted, purpose-limited communication identity so a scanner can share necessary information with an owner or intended recipient without either person needing to reveal who they are. The exchange exists to resolve one real-world need, then the connection ends.

SafeRelay is the communication protection engine inside ParkReply. It evaluates the purpose, behaviour, privacy risks, and safety risks in a message before deciding whether the useful information should proceed, be safely rewritten, or be stopped.

Vehicle stickers, key tags, wallet cards, and luggage tags are simply the first ways into the platform. ParkReply is solving a communication problem—not a QR problem.

Inspiration

The idea began with a simple observation: people often need to communicate without needing to know each other.

A QR code on a vehicle can help a stranger warn an owner about an open window. But the more important question is not how the scan happens. It is what happens after the scan: How can the stranger communicate without seeing the owner's phone number? How can the owner receive something useful without opening a channel for harassment, promotion, or unwanted personal contact? How does that channel close once the situation is resolved?

Those questions revealed a broader product opportunity. The same communication gap appears when someone finds keys, a wallet, an identity document, or luggage. It also appears in hotels, campuses, workplaces, venues, municipal services, and other environments where people may need a limited exchange but not an ongoing relationship.

We built ParkReply around a clear philosophy:

Purpose should come before identity.

A person should be able to say what matters without being required to expose everything else.

What it does

ParkReply creates a protected path between a public interaction and an intended recipient.

A person simply scans a ParkReply QR code—no account is required. They choose why they are reaching out, optionally add a message or photo, and submit the request. Before ParkReply notifies the owner, SafeRelay evaluates the communication using deterministic policy. The owner receives a protected, purpose-focused notification while both participants keep their personal contact information private.

In the Build Week demonstration, a user can choose from real-world vehicle, key, document, wallet, bag, and luggage scenarios—or edit a message manually. ParkReply passes that scanner-reported message through SafeRelay, its policy-driven communication protection engine.

SafeRelay then produces one of three outcomes:

  • ALLOW preserves a safe, relevant operational message.
  • WARN removes risks such as personal contact details or abusive wording while preserving the legitimate purpose; confirmation is required before continuing.
  • BLOCK stops threats, extortion, severe harassment, scams, phishing, unwanted personal contact, malicious promotion, or communication without a legitimate ParkReply purpose.

The result is not just a moderation label. ParkReply receives typed, explainable information including the product context, operational situation, communication purpose, behaviour, privacy and safety findings, risk level, decision reasons, safe rewritten message, owner headline, recommended action, scanner feedback, and notification status.

The experience deliberately avoids claiming that a real-world event has been verified. ParkReply interprets what the scanner reported; it does not assert that the event actually happened.

How we built it

We started with communication policy, not interface polish.

Before expanding the engine, we wrote a production-oriented SafeRelay communication specification covering product contexts, operational situations, purposes, behaviours, privacy categories, safety categories, risk levels, decision rules, precedence, rewrite rules, owner communication, and scanner feedback. That specification became the source of truth for deterministic behavior and tests.

We then implemented SafeRelay as a pure Dart engine with typed Flutter models. Keeping it stateless and independent from Firebase made every outcome local, fast, repeatable, and straightforward to test. Hard safety rules have explicit precedence: a useful intent or friendly phrase cannot downgrade a threat, extortion attempt, scam, or phishing message.

The engine detects and handles contact details, websites, messaging platforms, social handles, addresses, payment requests, bank details, crypto-wallet details, identity information, threats, harassment, blackmail, extortion, suspicious meeting requests, phishing, and malicious promotion. It supports English, French, and mixed-language Build Week scenarios.

The wider ParkReply application already provides the owner experience, QR infrastructure, and communication platform. During OpenAI Build Week, SafeRelay was developed as an isolated, deterministic trust engine designed to sit between the public scanner workflow and the owner notification flow before future production integration.

Throughout development, I used Codex with GPT-5.6 as an engineering collaborator to inspect the existing Flutter and Firebase codebase, identify messaging and authorization risks, refine the SafeRelay communication policy, and accelerate implementation of the standalone prototype. Codex assisted with code inspection, architecture discussions, implementation support, testing, and documentation, while all product decisions, architecture, and final validation remained under my control.

For presentation, we built a standalone Flutter Web entry point that launches only the ParkReply and SafeRelay demonstration. It does not initialize Firebase, connect to production messaging, access production data, or call an external AI service. The responsive product experience shows the full journey from raw scanner communication to a protected owner outcome.

The wider repository contains ParkReply’s Flutter experiences and existing Firebase-backed application services, but the Build Week trust engine remains intentionally isolated until server enforcement and production integration are designed safely.

Challenges we ran into

The hardest part was deciding what “safe” should mean without destroying useful communication.

A message can contain both legitimate information and bad behaviour. “You idiot, your headlights are on” should not reach the owner unchanged, but blocking it entirely would discard something useful. SafeRelay needs to remove the insult, preserve the operational fact, explain the rewrite, and require review. By contrast, an insult with no useful purpose should not be forwarded at all.

Classification precedence was another important challenge. Privacy exposure, frustration, and helpful intent are softer signals. They must never override threats, extortion, blackmail, severe harassment, scams, or phishing. We made that ordering explicit in policy and protected it with deterministic tests.

Rewriting introduced its own trust problem. A safe rewrite must not leak the original phone number, email address, payment detail, unsafe link, insult, or threat. It also must not invent facts, exaggerate urgency, or imply that ParkReply verified the real-world event. We added output invariants and scanner-reported wording to keep those boundaries clear.

Finally, we had to present a deep policy engine without turning the demo into a developer dashboard. The interface went through several rounds of hierarchy, responsiveness, scenario organization, empty-state, and runtime-layout refinement so a judge can understand the product in seconds while still inspecting the reasoning behind every decision.

Accomplishments we're proud of

We are most proud that the prototype demonstrates a coherent product model, not just a collection of moderation rules.

The current Build Week implementation includes:

  • 4 core product contexts
  • 16 communication purposes
  • 19 behaviour types
  • 11 privacy-risk categories
  • 11 safety-risk categories
  • 64 policy rows
  • 63 stateless policy outcomes implemented
  • 71 deterministic tests passing

We are also proud of the separation between ParkReply and SafeRelay. ParkReply remains the product and communication platform; SafeRelay is the embedded protection engine that makes the exchange trustworthy.

Most importantly, the prototype protects a simple promise:

Useful information can move forward without forcing personal identity to move with it.

What we learned

We learned that privacy is not just about hiding a phone number—it changes the shape of the product.

Once identity sharing is no longer the default, the communication needs a defined purpose, a clear lifetime, and a trustworthy ending.

We also learned that explainability belongs in the user experience. Deterministic policy and future AI enrichment complement each other: deterministic rules provide auditable boundaries and predictable behaviour, while future AI can improve contextual understanding without replacing those boundaries.

What's next

The next step is to move from an isolated, stateless demonstration toward enforceable platform architecture.

Our roadmap includes:

  1. Expanding deterministic policy coverage.
  2. Carefully introducing AI enrichment.
  3. Adding server-side enforcement.
  4. Detecting repeated abuse across conversations.
  5. Exploring responsible trust signals.
  6. Extending ParkReply into additional real-world communication contexts.

Continue expanding SafeRelay across additional ParkReply product contexts while preserving deterministic, explainable communication policies and privacy-first design principles.

These are future directions, not current capabilities.

OpenAI Build Week relevance

OpenAI Build Week gave us the opportunity to ask what must exist before intelligent communication assistance can be trusted inside a real product.

Rather than connecting an API first and defining safety later, we built the policy foundation first: deterministic communication rules, typed intelligence, explainable decisions, privacy-safe transformations, and comprehensive tests.

The current prototype does not call the OpenAI API, and it does not present deterministic pattern matching as AI.

Instead, it establishes a trustworthy foundation on which future AI capabilities can be introduced responsibly while preserving explicit, explainable, and testable communication policies.

Built With

Share this project:

Updates