InOrdo

Turn project updates into evidence-backed, human-approved recovery actions.

Comment

Evidence → deterministic impact → recovery proposal → human approval → reversible history.

Live application: https://inordo.vercel.app
Demo video: https://youtu.be/eDPB6wtkFrM
Source code: https://github.com/Chi944/InOrdo
Track: Work & Productivity

Inspiration

A project update rarely changes only one record.

If a summit venue moves by two weeks, the event date is obvious—but speaker confirmations, catering, programme deadlines, travel, accessibility arrangements, signage, and briefing materials may all become stale. Small teams often reconstruct that chain manually, under time pressure, with the source fact, inferred impact, and resulting edits scattered across different tools.

We built InOrdo to make that chain of reaction visible and controllable.

What it does

InOrdo turns an unstructured project update into a reviewable workflow:

  1. Preserve the evidence. A typed or pasted update is stored as the source of truth.
  2. Draft a candidate change. GPT-5.6 extracts a bounded structured interpretation while keeping source fact and model inference visibly separate.
  3. Calculate downstream impact. Pure TypeScript traverses explicit project dependencies deterministically, returning direct and indirect effects with readable paths.
  4. Draft recovery actions. GPT-5.6 receives the validated change and deterministic paths, then proposes a bounded set of recovery actions.
  5. Require human approval. Every proposal remains inert until an authorized person selects specific allowlisted actions.
  6. Preserve history and undo safely. Applied changes record before/after state and actor attribution. Supported operations can be reversed through a linked compensating operation rather than erasing history.

The submitted synthetic scenario is the Regional Climate Action Summit 2026: 24 active project records and 26 explicit dependencies. A venue update moves the summit from 12 September to 26 September 2026, allowing the reviewer to inspect its direct and multi-hop consequences.

What makes InOrdo different

InOrdo is not trying to replace broad work-management platforms.

Instead, it focuses on a narrower trust boundary that begins when new evidence invalidates part of an existing plan:

Evidence → structured change → deterministic reach → inert proposal → human approval → reversible history

The model interprets and drafts, but it never decides graph reach, authorizes itself, or directly mutates project data. This combination of preserved evidence, explainable dependency paths, selective approval, and compensating undo is the core product idea.

How we built it

InOrdo is a Next.js 16 App Router application using React 19, TypeScript, Tailwind CSS, Supabase Postgres and Auth, and the OpenAI Responses API.

The GPT-5.6 boundary is server-only. It has no tools or write authority. Strict schemas and application post-validation check identifiers, fields, values, dates, evidence spans, confidence, impact coverage, and allowlisted action types before model output can enter the review workflow.

Dependency reach is deliberately not delegated to the model. A pure TypeScript traversal handles cycles, duplicate edges, depth limits, deterministic ordering, and stable shortest paths over one project’s active records.

Supabase row-level security and server-side authorization enforce workspace and role boundaries. Before applying selected actions, the server rechecks proposal ownership, current item versions, action eligibility, human input, and idempotency. Supported undo operations recheck recorded after-state before creating a compensating transaction.

Codex accelerated concrete work packages across the repository foundation, schema and RLS design, deterministic graph engine, strict model contracts, approval and undo services, accessible interface, automated tests, security review, and release evidence. Deston and Andres retained responsibility for product direction, design decisions, credentials, provider spending, approvals, and release authority.

Challenges we ran into

Making AI useful without giving it authority

The model needed enough context to interpret an update and draft useful actions, but not enough authority to traverse the graph, approve work, or mutate data. We enforced that separation in server and database contracts rather than relying on interface copy.

Keeping graph results reproducible

Cycles, fan-out, duplicate edges, archived records, and multiple possible routes can make impact analysis ambiguous. We implemented bounded deterministic traversal with stable ordering and a best-depth policy so the same graph produces the same explainable paths.

Making undo honest

A button labeled “undo” is not sufficient. Safe reversal requires recorded before/after state, version checks, and a linked compensating operation. If state has become stale or the action is unsupported, InOrdo fails closed.

Recording a real demo without exposing unlimited API usage

We authorized exactly one purpose-specific Production GPT-5.6 run. After capturing and verifying the saved result, the recording key was revoked and Production returned to disabled analysis mode. Judges can inspect the genuine persisted result without being able to initiate paid requests.

Accomplishments that we are proud of

  • A coherent evidence-to-recovery workflow rather than an isolated AI feature.
  • One verified Production GPT-5.6 journey from preserved evidence through direct and indirect impact, recovery proposal, explicit approval, apply, linked history, and compensating undo.
  • A deterministic dependency engine with readable paths and coverage for chains, fan-out, fan-in, cycles, duplicates, archived items, maximum depth, ordering, and shortest-path behavior.
  • Server-enforced human approval and role boundaries; model output never directly mutates data.
  • A synthetic workspace containing six project-record types, 24 active records, and 26 explicit dependencies.
  • 514 passing unit and component tests across 64 files, two guarded Playwright Chromium journeys, a successful production build, and zero audited production dependency vulnerabilities.
  • A responsive, keyboard-accessible judging experience with an intentionally read-only viewer account.

What we learned

Structured output is only the beginning of a safe model boundary. Canonical-state validation, evidence checks, authorization, and deterministic application logic still matter.

Explainability becomes much stronger when graph paths—not generated prose—are authoritative for dependency reach.

“Human in the loop” must be a real server-side state transition. A checkbox alone does not provide control.

Finally, honest limitations improve a demo. Disabled controls and explicit read-only states are better than implying that unfinished or unavailable capabilities work.

What’s next for InOrdo

  • Add proposal correction and rejection workflows.
  • Expand ordinary workspace creation, invitations, and project switching.
  • Add authenticated end-to-end coverage and stronger operational monitoring.
  • Introduce reviewed text/Markdown and CSV ingestion before considering broader connectors.
  • Explore email, Slack, Teams, Google Drive, voice, and URL ingestion only after the standalone evidence-and-approval workflow remains reliable.
  • Extend reversible operation support while preserving the same fail-closed contracts.

Testing the submitted build

Judges receive a dedicated read-only account through Devpost’s private testing instructions. They can navigate the synthetic workspace, inspect records and dependencies, open saved evidence, follow deterministic impact paths, review the persisted GPT-5.6 proposal, and inspect apply/undo history.

New paid analysis and all project mutations are disabled for the judge account. The visible model result is the genuine saved Production result shown in the demo video.

Current limitations are intentional and visible: only the synthetic summit workspace is provisioned; ordinary-project creation is an informational preview; and file, CSV, URL, voice, email, Slack, Teams, and Google Drive imports are not implemented.

Built With

Share this project:

Updates