OpsBrief

Turn operational CSV data into a traceable executive brief with evidence-linked risks, prioritized actions, and clear management decisions.

Comment

Inspiration

In my day-to-day work, I work with operational data, service management, and management reporting among other things. One thing I have often found frustrating is that the data can be technically available, while the answer is still unclear even after working the data models over for hours.

A dashboard may show that something has changed, but it does not necessarily explain what matters most or what a manager should look at first. At the same time, I did not want to build something where AI could simply produce a convincing story without being tied to the actual numbers.

OpsBrief grew out of that question. I wanted to see whether I could combine reliable calculations with AI-assisted interpretation, while keeping every conclusion connected to visible evidence and save time and frustrations.

What it does

OpsBrief turns an operational CSV file into a traceable executive brief.

A user can upload a CSV or use the bundled synthetic service-desk dataset. The application then:

  • validates and profiles the data
  • calculates operational KPIs and monthly developments
  • records observation counts, limitations, and stable evidence IDs
  • uses GPT-5.6 to interpret the calculated evidence
  • identifies qualified connections between operational issues
  • prioritizes business risks
  • proposes sequenced management actions
  • validates every evidence, finding, risk, and action reference
  • presents the result in an executive dashboard and a downloadable complete Markdown brief.

The default Executive overview surfaces the main risk and the first recommended action. Individual KPI views provide charts, exact tables, evidence, and related findings. The Full brief preserves the complete evidence trail.

OpsBrief identifies associations and decision signals. It does not claim to prove root causes or replace managerial judgment.

How I built it

OpsBrief is built with Next.js, React, TypeScript, Zod, the OpenAI Responses API, and Vercel.

The analysis is deliberately divided into separate layers.

First, deterministic TypeScript code parses the CSV and calculates data-quality profiles, resolution time, SLA attainment, reopened work, customer satisfaction, monthly trends, observation counts, and limitations.

GPT-5.6 then receives structured aggregates and evidence objects rather than raw CSV rows. It produces the operational interpretation, a qualified narrative explaining how issues may connect, prioritized risks, and sequenced actions.

The response is parsed through Zod. Every finding must reference valid calculated evidence. Risks and actions must reference valid findings, and action dependencies must point to valid earlier actions. Invalid output can trigger one controlled repair attempt before failing safely.

Confidence is calculated afterward in code. It represents evidence coverage and traceability rather than model self-confidence.

The AI layer uses a provider-neutral InsightProvider contract. The OpenAI adapter is server-only, and the analysis engine remains independent from the React interface.

How I used Codex

I used Codex as an iterative development collaborator throughout the project.

Codex accelerated the initial Next.js and TypeScript implementation, deterministic analytics, provider architecture, OpenAI structured-output integration, Zod schemas, validation, automated tests, documentation, responsive dashboard work, and repeated quality checks.

Our workflow was iterative:

  1. I defined the product direction and acceptance criteria.
  2. Codex implemented and tested the next bounded change.
  3. I manually tested the result as an operations practitioner.
  4. We refined the product based on observed usability and credibility issues.
  5. Codex reran typechecking, linting, tests, builds, security checks, and documentation reviews.

I made the core product decisions, including the operational-manager audience, evidence-before-AI principle, provider-neutral architecture, qualified rather than causal language, management action sequence, and final executive-dashboard hierarchy.

Challenges

One major challenge was keeping deterministic facts separate from natural-language interpretation.

Another was validating a multi-level reference graph in which findings cite evidence, risks and actions cite findings, and action dependencies must remain correctly ordered.

The product also needed to explain related operational issues without presenting correlation as proven causation.

On the technical side, the project encountered a Next.js 16 multipart-routing interaction. The upload flow was changed to a strict JSON request envelope after tracing the framework behavior.

A final challenge was turning a long, technically complete report into a focused management experience without removing the underlying evidence.

Accomplishments

  • A complete production-deployed application
  • Live GPT-5.6 structured output
  • Deterministic KPI calculations and six-month trends
  • Evidence-linked findings, risks, and ordered actions
  • A manager-focused executive dashboard
  • A complete traceable Markdown export
  • Provider-neutral AI architecture
  • 30 automated tests across nine files
  • Desktop and mobile testing
  • Security, architecture, operations, and handoff documentation

What I learned

The project reinforced that AI output becomes easier to trust and challenge when facts and interpretation have explicit boundaries.

I also learned that confidence is more useful when it is derived from evidence coverage and validation rather than requested directly from the model.

Manual domain testing was essential. Technically correct output was not automatically management-friendly, and several of the strongest improvements came from reviewing the result as an experienced operations practitioner.

What's next

The next validation step is a comprehension test with a manager who does not have specialist service-desk or operational-analytics experience.

The result will be used to evaluate whether terminology, explanation, or information hierarchy needs further refinement.

Built With

Share this project:

Updates