Yumiko Expedition Control Room

A consent-first, provider-independent AI companion runtime that helps solo expedition travelers manage context, permissions, and decisions while keeping the human in control.

Comment

Inspiration

Long-distance solo travelers often make important decisions while route information, weather, devices, personal context, permissions, and AI assistance are scattered across separate systems.

Yumiko began as part of a real expedition project: preparing for a future motorcycle journey from Budapest to Yakutsk. The goal is not to build another chatbot, but an AI companion runtime that supports the traveler while keeping authority with the human user.

What it does

Yumiko Expedition Control Room demonstrates a consent-first workflow for an AI companion.

When the user asks Yumiko to use protected expedition route context, the system does not access that data automatically. Instead, it displays:

  • the exact requested scope;
  • why the information is needed;
  • where the data will remain;
  • how long access will be active;
  • a visible countdown for the session permission;
  • and an explicit Revoke access control.

The user may grant the minimum required permission for a limited session. Revoking it immediately removes access, blocks the protected workflow again, and creates a timestamped audit event identifying the human decision.

The Trust & Independence panel also makes important system boundaries visible:

  • conversation is available;
  • proposal creation is locked;
  • approval remains human-only;
  • autonomous execution is disabled;
  • and external AI access is not silently granted.

How we built it

The demonstration uses a local FastAPI backend with a JavaScript, HTML, and CSS interface. All displayed expedition information is labelled local sample data. No production database, private memory, API credential, or fabricated external model result is included.

Codex with GPT-5.6 Sol was used in a real CLI development session to:

  • inspect the existing repository;
  • implement a backend-enforced 30-minute permission lease;
  • add permission timestamps and remaining-validity state;
  • create the visible countdown and revocation interface;
  • enforce post-revocation denial;
  • expand automated lifecycle and UI tests;
  • identify and fix a missing pinned test dependency;
  • and update the repository documentation.

The complete lifecycle test verifies initial denial, permission grant, authorized local-data use, human revocation, post-revocation denial, and audit logging.

Verified Codex Thread ID:

019f8084-5783-7890-af0f-1e1f43a61a76

Codex contribution commit:

d0fe300e2ad106b98924b9c2ee1de3c7997274a9

Challenges we faced

The main challenge was demonstrating meaningful AI infrastructure without exposing real secrets, personal memories, or production data.

We therefore created a separate, secret-free evidence environment and clearly distinguished between:

  • the pre-existing Yumiko foundation;
  • the new Build Week Codex contribution;
  • local sample results;
  • and capabilities that are not yet implemented.

Another challenge was making consent visible as product behavior rather than describing it only as an architectural principle. Permission expiry, revocation, workflow blocking, and audit evidence therefore had to be implemented end-to-end.

Accomplishments that we are proud of

  • A working consent lifecycle rather than a static concept screen.
  • Human revocation immediately changes application behavior.
  • Permission duration and remaining validity are visible.
  • Tests verify the complete workflow.
  • The demonstration contains no production secrets or private user data.
  • Proposal, approval, and execution powers remain clearly separated.
  • The final demo video uses the project creator’s real narration.

What we learned

Trust in an AI system cannot depend only on what the assistant says. The product interface and backend must make access, duration, authority, and revocation independently visible and enforceable.

We also learned that provider independence is not only about switching models. Identity, memory, permissions, audit history, and human authority must remain part of the user-owned system.

What’s next for Yumiko

The next stages are:

  • persistent, user-owned permission and audit storage;
  • multi-device expedition support;
  • route and weather corridor intelligence;
  • device and cost-control panels;
  • voice interaction;
  • controlled AI-provider orchestration;
  • and field testing during the Budapest-to-Yakutsk expedition.

Yumiko is not intended to replace the human traveler. It is being built to help the traveler understand the situation, make better decisions, and remain in control.

Everything can be shown, but nothing is granted automatically.

Built With

Share this project:

Updates