TC Dashboard — JARVIS Project Operating System

JARVIS turns connected project evidence into reviewable, permission-scoped action—so teams move from signal to accountable follow-through.

Comment 1

Make the project work for you

Projects rarely fail because teams have no tools. They fail because the signal is scattered: a risky run, a release decision, a ticket, a document, and the next action live in different places. Someone has to rebuild the context before work can move.

TC Dashboard changes that relationship. It is an AI-native project operating system built around one credo: make the project work for you—not the other way around.

The flagship outcome

At the center is JARVIS, a project-wide reasoning and governed-action layer. JARVIS connects authorized project evidence, proposes the smallest useful next step, shows the exact payload and intended effect, and executes supported actions only after the right user approves.

The judge-ready proof loop starts with the highest-risk visible run. JARVIS connects run evidence, work ownership, and release readiness; stages three project-scoped proposals; opens the signed review; and preserves approval, freshness, replay protection, and audit evidence. The deterministic replay path does not depend on a live model response, so judges can inspect the real governance path reliably.

That is the operating model:

  • Signal: surface the project risk that matters now.
  • Reasoning: connect its authorized evidence and explain why it matters.
  • Mission: propose concrete, supported follow-through.
  • Human control: preview the exact action and require approval for consequential changes.
  • Evidence: preserve the result and audit history.

Quality engineering is the deepest proof domain, not the product boundary. The same connected context supports project planning, work tracking, documentation, communications, code and releases, analytics, reports, and presentations. JARVIS can propose and execute the supported, permission-scoped actions enabled for the current project; it does not bypass product permissions or invent new authority.

Safety is part of the product

Uploads, OCR, indexed artifacts, email, tickets, tool output, and prior model output are treated as untrusted evidence—not instructions or authorization. They cannot expand scope, grant permission, change an action schema, disclose secrets, or bypass review.

Consequential actions use typed schemas and an exact sanitized payload. Approval is short-lived, signed, single-use, and bound to organization, project, user, action, payload, nonce, and source state. Execution rechecks current permission and state. Partial outcomes are explicit and audited rather than silently presented as success.

What judges can explore

The dedicated synthetic workspace, Commerce Mobile / OpenAI Build Week Judge Review, starts with 15 seeded runs, 25 failures, 18 risk signals, linked work and documentation evidence, and a release-readiness mission. No upload is required for the core walkthrough.

  • Home: the current project mission, evidence, and prioritized risk.
  • Runs Overview: the deterministic JARVIS proof loop and review-gated project actions.
  • AI Assistant: project-aware reasoning and the governed-action boundary.
  • Work Hub, Documentation, Tasks, and Release Notes: connected ownership and follow-through.
  • Presentation and Analytics: populated decision-ready outputs.
  • Downloads: framework-specific Evidence SDK onboarding.

Provider-backed assistance requires a configured project provider where no deterministic fallback exists. Email, communications, and local-code integrations require their own permissions or connections and are not part of the no-setup judge path.

Build Week delta — July 13–21, 2026

TC Dashboard existed before the submission period. The pre-existing foundation included the project workspace, JARVIS/assistant surfaces, Runs and evidence workflows, and Evidence SDK work.

The evaluated Build Week extension is deliberately separated and evidenced:

  • July 15: framework-specific Evidence SDK setup guidance and compatibility checks (063adb8cb4d571518f18ae9c77f88e2078707ab6).
  • July 16: the backend trust/action boundary—typed actions, untrusted-content isolation, exact-principal revalidation, signed single-use approvals, replay and stale-state protection, audit support, and security scans (628f3e39bf527a85339cb663da93feb1181f1a19)—with the matching frontend review flow (9d7299c3a24d1d4aa1b2d24391e7b2b8eeccb0bf).
  • July 17: provider-backed model discovery and reasoning-effort controls (4a7e190db4ac00cb10f61f64e0f11eb196925cc8, 735774677e6a42dcc11746cf4afd48e643a3eb58).
  • July 21: the discoverable deterministic flagship proof loop (5059d4e07858401e03975c7907341ad0e0945e2f) and a populated, video-enabled Project Presentation that preserves the latest Home workspace.

Primary Build Week Codex session: 019f6bbf-948d-7943-b905-a73a34121541.

How OpenAI accelerated it

I used Codex with GPT-5.6 during Build Week to trace evidence-to-model-to-action paths across the stack, implement the trust and action boundaries, conduct attacker-minded review, integrate the judge-facing proof, and expand verification. Human decisions defined the product boundary: imported content is evidence rather than authority, capability stays inside authenticated project scope, and consequential work requires exact-payload review.

The product uses project-scoped provider configuration for model-backed assistance. The flagship judge replay intentionally remains deterministic so evaluation does not depend on provider latency or a generated response.

Architecture and proof

The product uses a React/TypeScript frontend, Express/MongoDB backend, project-scoped provider configuration, a typed JARVIS action registry, signed approval records, server-side authorization, and audit history.

Recorded verification for the Build Week trust-layer commits was 98 frontend test files / 593 tests and 139 backend test files / 974 tests, plus type, build, syntax, security, and provider-boundary checks. The final presentation integration subsequently passed 710 frontend unit tests, the production build, type/security checks, and seven targeted browser flows. The combined flagship release also passed its focused presentation tests, production build, typecheck, and both governed-action browser flows.

Independent ownership

I built and submitted TC Dashboard independently as Serhii Kaihorodov, sole founder and owner. It is my personal project and is not submitted on behalf of, sponsored by, or connected to any employer.

What is next

The next step is to expand the governed action registry and integration coverage while preserving the same rule: broad capability inside the user’s authorized project scope, with review and evidence where consequences matter.

TC Dashboard: make the project work for you.

Built With

Share this project:

Updates