BureauService

Privacy-first AI intake for small service businesses: GPT-5.6 structures operational requests, while the owner keeps the final decision.

Comment

Inspiration

BureauService began with Roman's real experience as a self-employed mobile massage therapist. Serving clients was only part of the job: he also had to answer repeated messages, collect the right details, plan his day, and keep track of requests while travelling between appointments.

Existing tools often felt too expensive, too complicated, or designed for larger companies. We asked a practical question: can a small service operator turn an unstructured request into a useful work record without giving AI access to personal data or control over the final decision?

What it does

BureauService turns a synthetic, non-personal service request into a validated structured intake for the business owner.

  1. The user provides operational preferences: service, duration, preferred date or time, and city.
  2. A local privacy gate runs before every model call. It blocks names, contact details, exact addresses, Telegram identifiers, and health or medical text.
  3. GPT-5.6 receives only an allowlisted operational projection and returns strict structured fields.
  4. Local code validates every returned value against the safe source data and service catalog. Unsupported or invented values are rejected.
  5. The owner receives an AI-assisted review card and decides whether to approve, decline, or suggest another time.

The request remains pending until an authorized human acts. GPT-5.6 cannot diagnose, confirm a booking, or perform an external action.

What was new during Build Week

The public SpineMobile website existed before Build Week and provides the real business context. It is not connected to the contest prototype and is not claimed as Build Week functionality.

During Build Week we created the isolated GPT-5.6 intake and owner-review module in our repository:

  • a separate Telegram staging bot using synthetic demo data;
  • a pre-model privacy filter and allowlisted operational projection;
  • OpenAI Responses API integration with GPT-5.6;
  • strict structured output with local anti-invention validation;
  • a human-controlled request state machine;
  • allowlisted owner actions with version checks and idempotency;
  • fail-closed configuration, identity, and model-evidence checks;
  • automated privacy, schema, state-transition, and failure tests.

How we built it with Codex and GPT-5.6

Roman defined the real workflow, the information an owner needs, and the rules that must never be violated. Max translated those rules into acceptance criteria and collaborated with Codex to inspect the architecture, implement the isolated workflow, identify bypasses, and build reproducible tests.

Codex was most valuable when the requirements were concrete: what data must stay local, which output fields are permitted, which failures must close the workflow, and which decisions must remain human.

GPT-5.6 performs one deliberately narrow task. It normalizes safe operational preferences into service_code, duration_minutes, preferred_date_or_period, preferred_time, city_or_postcode, missing_fields, ambiguity_flags, and follow_up_field. It does not receive raw identity or health information and does not generate customer-facing decisions.

Challenges we ran into

The hardest problem was not generating text. It was limiting what the model could see, return, and influence.

A prompt alone was not enough. We needed a local privacy boundary before the model call, a strict schema, and source-binding validation after the response. We also had to ensure that missing credentials, timeouts, invalid output, or privacy violations could never look like a successful live GPT result.

The Telegram workflow added more risks: separating staging from the public bot, preventing stale buttons from changing new requests, restricting owner actions, and keeping tokens and identifiers out of errors and evidence.

Accomplishments that we're proud of

  • 55 automated tests pass with 0 failures.
  • The final 33-file submission scope produces 0 secret-scan findings.
  • Live GPT-5.6 output is schema-validated and locally source-validated.
  • The staging flow remains PENDING_OWNER_REVIEW until the owner acts.
  • Final confirmation explicitly records that it was a human decision, not an AI decision.
  • Redacted evidence and exact reproduction instructions are included in the public repository.

What we learned

The useful role for AI here is not autonomous decision-making. It is narrow normalization between human input and human review.

Privacy must be enforced before the model call, not only described in a prompt. Structured output is also not sufficient by itself: every returned value still needs local validation. Clear limitations make a prototype more credible and easier to evaluate.

What's next

Before any production use, we plan to add persistent storage with explicit retention and deletion rules, rate limits, retry/outbox handling, an auditable owner-action history, broader adversarial testing, full localization, accessibility testing, and legal/privacy review.

Only after those steps would we consider opt-in website or calendar integration. Our longer-term goal is to adapt the same human-controlled workflow to trainers, cleaners, repair specialists, tutors, and other small service businesses.

Honest scope

This is an isolated staging prototype using synthetic data and in-memory state. It is not connected to the public website, calendar, WhatsApp, payments, routes, or production customer systems. No real customer data should be used with this prototype.

Built With

Share this project:

Updates