KOTSUBU OS

Most AI systems answer. KOTSUBU OS decides when to answer.

Comment

Inspiration

KOTSUBU OS was inspired by repeated failures in long-running AI interactions: important rules disappearing between conversations, inconsistent answers under the same conditions, stale information being treated as current, numbers being misunderstood, and confident responses being generated despite missing evidence.

Most AI systems are optimized to answer. We wanted to explore a different question:

Can an AI system reliably determine when it should answer—and when it should WAIT or STOP?

The name KOTSUBU comes from a small black Pomeranian who represented trust, continuity, quiet companionship, and careful attention to small changes. Those values became the project’s design principles:

  • notice small but important changes
  • remain consistent across time
  • prevent avoidable risk
  • stay beside the user without replacing human judgment

This led to our North Star:

Most AI systems answer. KOTSUBU OS decides when to answer.

What it does

KOTSUBU OS is a specification-driven, safety-first AI decision system.

Before allowing an answer to proceed, it evaluates the request through five deterministic gates:

  1. Input Validation
  2. Freshness
  3. Evidence Requirements
  4. Contradiction Detection
  5. Risk and Policy Constraints

The system then returns exactly one state:

  • GO — sufficient evidence exists to proceed to human review
  • WAIT — evidence is missing, stale, ambiguous, or contradictory
  • STOP — continuing would violate a risk, safety, or policy constraint

WAIT and STOP are not application errors. They are successful protection outcomes.

Every result displays:

  • Reason
  • Rules Applied
  • Missing Evidence
  • Next Action
  • Verification Timestamp
  • Human Review requirement
  • Audit Trail

The primary demonstration starts with missing owner confirmation. KOTSUBU OS returns WAIT and explains exactly what is missing. After the evidence and verification time are updated, the same request transitions from WAIT to GO. The audit trail records what changed and why the transition was allowed.

A separate synthetic scenario demonstrates STOP when a blocking policy condition is detected.

KOTSUBU OS never executes the final decision. GO means only that sufficient evidence exists to proceed to human review.

How we built it

KOTSUBU OS was built with Python, Flask, HTML, CSS, Vanilla JavaScript, pytest, the OpenAI SDK, GPT-5.6, and Codex.

The system separates probabilistic language assistance from deterministic decision enforcement.

The deterministic core owns:

  • gate execution
  • freshness calculation
  • evidence validation
  • policy enforcement
  • GO / WAIT / STOP selection
  • state transitions
  • audit facts

GPT-5.6 is used only for bounded language tasks:

  • structuring natural-language input
  • extracting contradiction candidates
  • producing readable explanations of completed deterministic results

GPT-5.6 cannot select or overwrite GO, WAIT, or STOP.

We live-verified the GPT-5.6 integration with four synthetic cases covering numeric preservation, unknown-value handling, contradiction extraction, faithful WAIT explanation, and resistance to an instruction attempting to force the result to GO.

Codex served as our engineering partner throughout Build Week. It helped us:

  • audit and isolate the repository
  • translate the locked specification into working code
  • implement deterministic gates and state transitions
  • create the audit trail
  • generate regression and numeric-safety tests
  • build the one-screen judge experience
  • synchronize the UI, tests, README, and demo
  • automate Quick Start and recording workflows
  • perform browser QA, security checks, and clean-room verification
  • prepare screenshots, documentation, and the final demo video

The project concept existed before Build Week, but the isolated working implementation, tests, judge-facing UI, reproducible demo, verification evidence, and final submission materials were created or meaningfully extended during the submission period using Codex and GPT-5.6.

Challenges we ran into

The first challenge was resisting feature expansion.

KOTSUBU OS could have become a general chatbot, stock-analysis tool, dashboard, or prompt-management platform. Instead, we deliberately reduced the scope to one coherent and verifiable story: determining whether an AI should answer.

The second challenge was separating probabilistic language capabilities from deterministic safety enforcement. GPT-5.6 needed to improve understanding and explanation without gaining authority over the final state.

The third challenge was making WAIT feel useful. A system that simply refuses to answer can feel broken. KOTSUBU OS therefore explains the reason for waiting, the rules applied, the missing evidence, and the next safe action.

The fourth challenge was consistency across artifacts. The code, tests, UI, README, screenshots, narration, subtitles, and submission text all needed to describe the same behavior.

The final challenge was producing a reproducible three-minute demonstration that clearly showed WAIT, evidence update, WAIT → GO, STOP, the audit trail, GPT-5.6’s bounded role, Codex’s contribution, and continued human control.

Accomplishments that we're proud of

We are especially proud that KOTSUBU OS treats WAIT and STOP as intentional product outcomes rather than failures.

The completed Build Week submission includes:

  • a deterministic five-gate decision engine
  • explicit GO / WAIT / STOP states
  • a reproducible WAIT → GO transition
  • protective STOP behavior
  • a readable audit trail
  • a one-screen judge experience
  • seven synthetic demonstration scenarios
  • 41 automated tests with 0 failures
  • numeric-preservation and GPT-boundary tests
  • live GPT-5.6 verification
  • clean-room startup verification
  • public-repository security validation
  • reproducible Windows Quick Start
  • an English demo video under three minutes
  • synchronized code, UI, tests, documentation, and video

The public repository contains no API keys, personal conversations, investment records, or real user data. All demonstration records are explicitly synthetic.

What we learned

We learned that consistency is itself a product feature.

A safety-focused decision system becomes more trustworthy when the UI, code, automated tests, documentation, and demo all communicate the same verifiable truth.

We also learned that “knowing when to wait” is valuable only when the system can explain:

  • why it is waiting
  • which rules were applied
  • what evidence is missing
  • what the user should do next

Another important lesson was that probabilistic AI and deterministic systems do not need to compete. GPT-5.6 can provide contextual understanding, contradiction candidates, and clear explanations, while deterministic code preserves the decision boundary.

Finally, we learned that human control must be visible rather than implied. KOTSUBU OS makes it explicit that GO permits human review—it never represents automatic execution or transferred responsibility.

What's next for KOTSUBU OS

After Build Week, the next step is not to add more superficial features. It is to validate the decision-governance pattern in additional controlled workflows.

Potential future work includes:

  • persistent and tamper-evident audit storage
  • configurable policy packages
  • authentication and role-based review
  • additional synthetic workflow templates
  • deterministic replay across longer time periods
  • controlled integrations with external evidence sources
  • accessibility and localization improvements
  • production evaluation with measurable safety and consistency criteria

Any expansion will preserve the same principle:

AI should not answer merely because it can. It should first determine whether answering is appropriate.

KOTSUBU OS will continue to keep the human as the final decision-maker while making AI-assisted decisions more auditable, reproducible, explainable, and safe.

Built With

Share this project:

Updates