Tim Brand.

← Back to selected work

Case study / Accountable AI workflows

AI
Operations
Dashboard

Outside the conversation.
Inside an accountable record.

I led a shared dashboard for AI-assisted projects, bringing scope, progress, verification and spending into an authenticated application. The aim was not another progress percentage. It was a record people could inspect.

Role / Requirements + direction + release scope

Evidence / September 2026 release records

Platform / Django + Linux

Original conceptual workflow

A bounded update.
A reviewable history.

Conceptual workflow: an authorized project member submits an update with a meaningful event; project and role checks gate a committed status and history record. Review separates reported from verified work and subscription allocation from estimates and invoices.
Conceptual workflow, not an application screenshot or deployment topology. Time-sheet entries require attributable records and an authorized writer; this is not automatic usage ingestion.

01 / The problem

“Done” needs
a definition.

Chat histories are useful working spaces, but weak shared operational records. A completion claim can hide an unfinished acceptance check. Elapsed time can be mistaken for active AI work, and a provider estimate can look like a paid charge. Different people and agents also need different access.

The dashboard gives each project an objective, completed work, verified results, blockers and a next action. Ordered milestones and retained events explain how the project reached its present state, without replacing existing milestone plans.

My role: operating requirements and release judgment

I set requirements, directed AI-assisted implementation and integration, reviewed the experience and controlled release scope. That included diagnosing the actual deployment route, separating application health from proxy and certificate problems, and checking authenticated behavior after release.

02 / Access + architecture

Share the application.
Not unrestricted authority.

One Django application and SQLite database served multiple projects. A Debian container hosted Nginx and Gunicorn behind an approved HTTPS reverse proxy. Gunicorn used a Unix socket rather than a network listener. Sign-in protected project pages and evaluation routes.

An agent needs an active identity and membership on the exact project. Reader, publisher and orchestrator roles express distinct permissions. Project-bound credentials expire by default; status-publishing authority does not grant access to another project or permission to write time entries.

Updates require a meaningful event. Invalid values or nonexistent milestone references reject the whole request. A successful change and its history event commit together, retaining the acting identity and whether the event is reported or verified. An agent assertion is not independent verification.

03 / Accounting

Keep the basis
beside the amount.

The append-only time sheet distinguishes fixed-subscription allocation, provider-token estimates and invoice-confirmed charges. Corrections supersede an entry rather than erase it. Current totals exclude superseded rows so an estimate and its later invoice are not counted twice.

  • Historical session-turn elapsed time remains reconstructed history, including possible tool waits, not measured active labor.
  • New active-work claims require attributable timing evidence.
  • The budget gauge shows remaining budget and overage while separating authorization limits from editable planning figures.

04 / Controlled release

A passing test suite
is not the whole release.

A release helper uses an allowlisted file manifest and expected old and new hashes. It checks starting health, freezes reviewed files, integrity-checks a private database backup, runs Django checks and tests, applies approved migrations, restarts the application and checks socket health. Failure triggers code and database rollback attempts.

An early time-sheet release passed application tests but hit a backup-directory permission boundary. Rollback restored the prior application. Another stale candidate failed two budget-gauge tests and was rolled back; rebasing on the actual live version resolved the mismatch.

05 / Recorded acceptance

Evidence belongs
to its checkpoint.

These are historical September 2026 release records, not fresh availability checks. Test counts belong to separate checkpoints, not a cumulative independent campaign.

  • September 26 foundation: HTTPS health returned 200, anonymous access redirected to sign-in, and Gunicorn had no TCP listener.
  • Credential-panel removal: 34 tests passed; authenticated rendering confirmed its absence, including administrator coverage in tests.
  • September 29 time sheet: 48 tests passed, migrations applied, and browser checks showed a populated project and shared empty state.
  • Budget and layout: 50 tests passed; browser review checked the breakdown at a narrower viewport.
  • Project operating standard: 53 tests passed; the release gate completed and protected routes retained sign-in redirects.

06 / Outcome + limits

Clearer operations.
Bounded claims.

The delivered application provided a common review surface for project status, evidence labels and AI accounting. Authorized agents could publish bounded, attributed updates, while financial records retained how each amount was derived.

What this delivery does not establish

The time sheet did not automatically ingest all AI usage. Entries still needed source records and an authorized writer. Scheduled review was not a continuously running agent. Django authentication did not establish enterprise SSO, high availability, large concurrent-user capacity or tested disaster recovery. Adoption, productivity gains and measured ROI were not demonstrated. Removing one credential panel was not a comprehensive security certification.

The wider picture

Trust starts with
enforced distinctions.

Back to selected work