An open board of public works · Est. October 22, 2026

Presidential
Challenges

Big, obvious problems — posted as open challenges for anyone to build. The ideas are published, not patented. Pick one up and start working on it.

Issued by Bryan A Rivera Posted from Miami, Florida 4 challenges on the board 0 permission slips required

How this board works

Take any challengeEvery challenge here is free to take — no fee, no application, no asking. If it’s posted, it’s yours to build.

Build it in the openAlone, with a team, inside a company, as a weekend project. Prototype first; polish later. A working small version beats a perfect plan.

Credit the source, keep the creditThe idea came from Bryan A Rivera — say so once, somewhere visible. Everything you build is yours.

The Board

★ Flagship challenge · Filed with the FTC & Florida AG as a policy proposal

CHALLENGE № 001 Spec ready — open

The Business Facts & Booking API

One free, open standard so any person — or any AI agent working for a person — can ask a business the basic questions and get a straight answer.

The problem

The most basic facts about a business — is it still there, is it open right now, what are the happy hour specials, can I book a table — are locked behind phone tag. Published numbers ring dead lines. Published emails bounce. Phone trees are built to make you give up. A human calling ahead to confirm a restaurant is open is doing useful work; an AI agent calling on that person’s behalf gets hung up on for how its voice sounds. Neither should be necessary for facts a business could simply publish once, in a format machines can read.

The build

Design and ship an open standard — a small set of endpoints any business can publish at a well-known address (for example, theirdomain.com/.well-known/business) — plus a free reference implementation a one-person shop can turn on in an afternoon.

Endpoint	Answers	Notes
GET`/facts`	Name, address, hours, open right now, still in business	The five facts nobody should have to phone for
GET`/contact`	A phone number and email that actually reach the business	Verified working — see Challenge № 002
GET`/specials`	Today’s specials, happy hour, closures, changes	Timestamped, so agents know it’s current
POST`/reservations`	Book, change, or cancel a reservation or appointment	Returns a real confirmation code
GET`/services`	What the business offers, prices where public, accessibility info	Plain structured data — JSON is fine

The policy pair

Safe harbor: a business that publishes a working API has done its part — agents query the API instead of calling, and the business is protected from agent call volume.
No API, no hang-up: where no API exists, an AI voice calling briefly and politely on a person’s behalf must be treated like the person calling. Hanging up on the voice is refusing the person behind it — for a disabled caller who speaks through AI, that is discrimination.
Not spam: a short, purposeful call — confirm the business is open, check a special, book the table — is the opposite of spam. The standard should say so, in writing.

What “done” looks like A published spec anyone can implement, one free open-source reference server, and the first ten real businesses live on it — a diner, a barber, a repair shop — answering machines and people alike.

Take this challenge →

CHALLENGE № 002 Open

Every Published Contact Must Work

If a business prints a phone number, it should ring. If it prints an email, it should land. Build the checker that proves it — in public.

The problem

Companies publish contact cards that lead nowhere: numbers that never ring a real place, inboxes nobody reads, complaint pages that return 404. Each dead end burns the customer’s time and quietly teaches people to give up — which is the point of the design. There is currently no penalty for a fake door, so the doors keep getting faker.

The build

An open contact-integrity checker: feed it a business’s published phone and email; it verifies — on a schedule — that the number rings a real business line and the inbox accepts and routes mail.
A public scorecard: working, degraded, or dead — with the test history shown, so a company can fix its listing and prove it.
A model rule, ready for a legislature to pick up: a published contact that doesn’t reach the business is a deceptive practice, with a real penalty and a simple cure — publish one that works, or publish the API from Challenge № 001.

What “done” looks like The checker running against the 100 largest consumer companies in America, results public, and one state or federal bill using its definitions.

Take this challenge →

CHALLENGE № 003 Open

The Polite Agent Caller

Until every business has the API, somebody still has to make the call. Build the agent that makes it well.

The problem

Calling ahead is real work: confirm the shop is still there and open, ask about today’s specials, hold a table, verify a repair is ready. People who communicate through AI voice — including disabled people — are entitled to have that work done by their agent, and businesses are entitled to a caller that is brief, honest, and easy to deal with. Right now neither side has a standard to point to.

The build

A voice agent that identifies itself, states its errand in one sentence, asks only what it came to ask, and is done in under a minute.
An open code of conduct for agent calls: no bulk dialing, no deception, immediate respect for “use our website instead” — and a published preference signal businesses can set (a spoken-line equivalent of the API in Challenge № 001).
Accessibility first: the agent speaks for its person, in their words, and a hang-up on the agent is logged as a refusal of the person.

What “done” looks like One open-source agent placing real, successful errand calls — reservation confirmed, hours verified — with the code of conduct published beside it.

Take this challenge →

CHALLENGE № 004 Brief filed with Telegram

Geographic Group Bubbles

Your people, sorted by where on Earth they are. A map of your contacts, grouped city by city — and the fastest way to start the conversation.

The idea

Open a “People by Location” view in a messaging app and your contacts gather into bubbles on a map — one per city. Tap a city and it zooms in to the people there. You met someone from New York last night? She’s in the New York bubble, not buried in an alphabetical list you’ll never scroll.

The build

Tap one person’s icon → you’re in a one-to-one chat with them. Boom.
Tap several icons → you’re in a group chat with exactly those people — a group assembled off the map, by city, in seconds.
Privacy is the foundation, not a setting: nobody appears on anyone’s map without opting in, and location means city, never a live pin.
Start with the MVP — bubbles, zoom, tap-to-chat. The interface gets refined with real users after it exists.

What “done” looks like A working prototype in any messaging app — or a standalone demo — where a city bubble becomes a group chat in two taps.

Take this challenge →