Stradviso & Decision Studio

AI proposes. Humans decide. Stradviso turns ambiguous client requests into approved, traceable project changes.

Comment

Stradviso Decision Studio

From ambiguous client requests to approved, traceable project changes.

Built by Stefan with Codex, with a controlled GPT-5.6 Sol integration inside Decision Studio.

TL;DR

I am Stefan Raijmakers, 42, and I live in Tiel, the Netherlands. My role is closest to product architecture: I bring the customer problem, product direction, visual identity, and practical experience together, then stay involved until the result becomes something people can actually use.

During Build Week, I used Codex to build the submitted Stradviso Business OS repository: an authenticated backoffice, a customer project workspace, and Decision Studio.

Decision Studio is the human-controlled layer for difficult project choices. It helps turn an unclear client question into clarification or bounded options, but it does not allow AI to make the decision or write directly to project state.

AI proposes. A human decides. Deterministic application code controls what may actually change.

Inspiration

I started Stradviso because strategy too often ends as a presentation while the difficult work begins afterwards.

Project collaboration is usually spread across email, messages, calls, meetings, and documents. A client may ask for a change that sounds simple, but a responsible answer can require reconstructing the current scope, earlier decisions, risks, dependencies, and commitments. Important context gets lost, and an idea can quietly become a promise before the consequences are understood.

I did not want to build another generic dashboard or contact form that simply collects a question and leaves it in an inbox. I wanted to create a better place for the conversation itself: somewhere clients and project teams can examine a request together, understand what is missing, and preserve responsibility for the final decision.

My background is not the traditional path of a software engineer building every technical layer alone. I have worked across commercial development, logistics, digital services, websites, data, and AI. I think about the whole first: what a business is trying to achieve, how a product should feel, how people move through it, what they need to understand, and whether all the parts belong together.

Build Week gave me the opportunity to turn that way of thinking into a working system.

What I built during Build Week

The Stradviso name, consultancy concept, an early AI-assisted logo concept, and limited go-to-market materials existed before Build Week.

A separate Stradviso public-website project began on 14 July 2026, after the Submission Period opened, but it is not part of the submitted Business OS repository. The submitted repository history begins on 16 July 2026, and the submitted Stradviso Business OS and Decision Studio software was developed during the event period.

The repository contains:

  • an authenticated Business OS backoffice;
  • a role-aware customer project workspace;
  • project collaboration and controlled record workflows;
  • Decision Studio and its governed decision-to-execution boundary;
  • reproducible tests, evidence, privacy controls, and release safeguards.

The Build Week focus is deliberately narrower than the full Business OS vision. The central proof is Decision Studio: one important client request moving from uncertainty to an accountable project decision.

What Decision Studio does

Decision Studio is designed for questions that sound simple but affect several parts of a project. For example:

Can we launch two weeks earlier without increasing the budget or reducing onboarding quality?

The Build Week walkthrough uses clearly labelled synthetic project data and two separate runs:

  1. Clarify: when material information conflicts or is missing, the system returns one focused blocking question, zero scenarios, and no approval path. It does not pretend the answer is already known.
  2. Decision-ready: a separate run with sufficient context presents three bounded scenario options for review.

An authorized person can approve one exact option. That approval is bound to the actor, project revision, proposal, and context that were actually reviewed.

Before anything changes, deterministic application code checks authorization and freshness again. If the approval is still valid, the submitted allowlist permits one Decision, one Risk, and one Milestone update in a single transaction. A bounded receipt preserves the selected scenario, approval, and linked records.

If the project context has changed, the earlier approval becomes stale. The application refuses the update and writes zero project records. Recovery clears the old approval state so that fresh review is required.

The important boundary is simple: model output has no direct database authority.

How I built it with Codex and GPT-5.6

I could not have built this project alone. I started Build Week with the product vision, the customer problem, the design direction, and a clear feeling for how the experience should work. Codex helped me turn that direction into architecture, interfaces, workflow code, tests, adversarial checks, documentation, and release preparation.

I remained responsible for the product decisions: the client problem, the human-approval boundary, the narrow write allowlist, the visual direction, the synthetic judging approach, and the standard each claim had to meet. I reviewed and redirected the work whenever something was technically correct but not yet clear or useful enough for a client.

Decision Studio's controlled real lane targets gpt-5.6-sol through the OpenAI Responses API with store:false. Only bounded project context that the current user is authorized to use is eligible for the request. The application expects a versioned JSON brief and performs its own strict schema and semantic validation. store:false is a request setting, not a universal zero-retention claim.

The project includes independently accepted bounded real checkpoint evidence for the provider boundary. That evidence is intentionally narrow: it proves that the controlled route was exercised, not model quality, superiority, or a completed multi-case evaluation. The deterministic walkthrough uses labelled fixture data and never presents fixture output as a live model response.

The main application stack includes PHP 8.3, Laravel 13, Livewire 4, MySQL and SQLite, JavaScript, Tailwind CSS 4, Vite, and PHPUnit.

Challenges I ran into

The hardest challenge was not making AI produce an answer. It was deciding what AI should and should not be allowed to do.

Valid JSON is not automatically a safe project decision. Model output, deterministic validation, human approval, and project writes therefore had to remain separate failure domains.

A second challenge was keeping a large AI-assisted build coherent. Long sessions can accumulate old assumptions and unclear context. I learned to restart with a focused goal, divide complex areas into bounded tasks, use separate agents where helpful, and keep returning to the same questions:

  • What should the client understand?
  • What should feel natural?
  • What is genuinely needed?
  • Does this still fit the vision of Stradviso?
  • What evidence supports the claim?

The third challenge was scope. The Business OS grew quickly, but the strongest submission was not the one with the most screens. It was the one that made a single decision boundary understandable and testable.

Accomplishments I am proud of

I am proud that this is not just an isolated chatbot or a visual mock-up. Decision Studio sits inside a project workspace and connects AI-assisted analysis to the records where project commitments live.

The submitted control layer and synthetic proof cover:

  • one blocking clarification with no invented scenarios;
  • three bounded options in a separate decision-ready run;
  • exact human approval;
  • one atomic Decision, Risk, and Milestone update;
  • stale-context refusal with zero writes;
  • recovery that requires fresh approval;
  • bounded receipts and reproducible evidence.

I am equally proud of the honest boundaries. Fixture evidence is not described as live model evidence. One provider checkpoint is not described as a quality study. The project does not claim universal accuracy, compliance, customer impact, or production readiness.

Answers can be generated. Decisions must be earned.

What I learned

This project taught me that trust often depends on details that are not immediately visible.

The right person needs to see the right information. Approval must belong to the situation that was actually reviewed. When that situation changes, the system needs to say so instead of quietly continuing.

I also learned that I do not have to build every technical layer by myself to create a serious product. My role is to hold the wider vision, keep asking the human questions, and decide when something is clear enough, useful enough, and true enough to the idea.

Codex helped turn that direction into structure, code, tests, and working processes. The result became stronger when I added context, challenged assumptions, and refused to let a polished answer replace evidence.

Known limitations

  • The submitted mutation allowlist is deliberately limited to Decision, Risk, and Milestone records.
  • The clarification and decision-ready demonstrations are separate synthetic runs. Answering a clarification question does not yet create the successor run automatically.
  • Model output can be incomplete or wrong, so human approval remains mandatory.
  • Synthetic demo data is not evidence of real-customer handling or commercial validation.
  • Voice, cross-vendor benchmarking, and broad external integrations are outside the submitted scope.
  • No claim is made of universal accuracy, security, retention, compliance, uniqueness, or customer impact.

What is next

Stradviso Business OS is the broader direction. Decision Studio is the first part I have made concrete, testable, and useful.

The next steps are to improve the clarification-to-successor workflow, deepen project context, expand reporting and customer collaboration, and add controlled integrations with systems such as CRM platforms. Broader evaluation and review can grow from the evidence framework already in place.

Voice and richer interaction may follow later, but only when they strengthen the same human-control boundary rather than distract from it.

The long-term goal remains the same: give important client questions a clear, human, and traceable route to a decision people can understand, review, and stand behind.

Built With

Share this project:

Updates