Forge

A ticketing system that writes its own tickets.

The board is what an investigation produces.

The old way

The ticket used to be a guess. Now it’s an output.

In Jira, Linear, or Asana, a ticket is where the thinking stops and the typing starts.

Someone decides what to build, writes it down, and hopes the words carry the reason.

The reason never travels. The evidence stays in a dashboard. The “why” lives in someone’s head.

Vernais flips it. You investigate. You choose a Solution. The board writes itself, and every Task still points back to the evidence that caused it.

01 · Decompose

From a fix to a board

The chosen Solution auto-decomposes into concrete work.

Visual

Solution IN-42-S1 decomposing into three typed Tasks, each with its own title, type, and state machine: IN-42-T1 tech, IN-42-T2 design, IN-42-T3 non-tech.

You promote a Solution (IN-n-S1) in Decide. Vernais reads the root cause and the solution blueprint, then carves it into Tasks, each with a real title, a type, and its own state machine.

Every Task gets a human-readable ID: IN-n-T1, IN-n-T2, IN-n-T3. Trace any card back to its Solution, its Hypothesis, and the Case file behind it.

Three task types, three state machines

Each type carries the right stages by default. No forcing a copy task through an engineer’s workflow.

tech

Code work

Runs through a ladder wired to real git and a Sentry gate.

design

UI & asset work

Its own review-and-approve stages, tuned for design.

non-tech

Content, ops, comms

A lighter draft-to-ship flow, with no engineering gates.

02 · Act

The board and the plan

One surface holds the doing and the scheduling.

Kanban board

Columns are your workflow stages: the real ones you edited, in the colors you chose.

  • Drag a card to move the work. The state machine keeps the transitions honest.
  • A live gate badge on each card shows where a technical Task stands: Verifying, awaiting review, Regression, Verified.
  • Blockers surface where you can see them.

Gantt plan

A schedule built from reality, not wishful dates. The scheduling engine plans by real capacity, task dependencies, and committed dates, not by dropping bars onto a timeline and hoping.

  • Dependencies push dependent work to its earliest honest start.
  • Capacity means the plan respects who’s actually available.
  • Committed dates anchor the work that has to land on time.

Triage & My Tasks

  • Triage: a fast lane to sort incoming work before it hits the board.
  • My Tasks: a personal, cross-initiative queue. Every Task assigned to you, from every initiative, in one place. One click drops you into the task drawer.

03 · Assign

The best person for the job

For every ticket, Vernais ranks your teammates with a score and a plain “why.”

You don’t guess who should take a Task. Vernais reads what the Task needs, looks at who’s free, and puts the best fit at the top.

What the ranking weighs

01

Role-fit for the ticket type

A tech Task favors engineers; a design Task favors designers. The match is grounded in the ticket type and each person’s role.

02

Real current workload

How much is already on their plate, right now.

03

Time-off & availability

The earliest-start estimate is grounded in who’s actually around.

Every recommendation shows its reasoning in plain language, so you can agree or overrule.

Today the score is role-fit plus real current workload and availability. Past-work-history weighting is on the roadmap, and it sharpens as the workspace accrues history. A fresh workspace has no history to weigh yet, so early ranking leans on role-fit and load.

04 · Verify

It self-advances

Technical tickets move themselves when the code moves.

The GitHub dev panel

The exact Jira dev panel, wired to real GitHub through your connected token.

  • Create branch: pick the repo, name the branch <type>/<task_ref>-<slug>, choose a base. Vernais creates it on GitHub.
  • Commits: the panel tracks real commits on the branch as they land.
  • Pull requests: open PRs show up with their live state, including MERGED.
  • Builds: CI check runs surface pass or fail, with a link to fix.
  • Merge: merge to main from the panel. The Task advances to Verifying and opens the gate.

Git signals do the transitions. Branch created, PR opened, build green, merged: the Task walks its ladder without a status meeting.

The Sentry verifying gate

Merge is not done. A real gate watches production after the merge. Vernais reuses your already-ingested Sentry data. After a Task merges, the gate soaks, pinned to the actual deploy, and attributes new production errors back to the work.

  • It scores each Sentry issue against the Task: task reference, commit SHA, release version, service, deploy window.
  • A strong, code-confirmed match auto-files a regression sub-bug onto the Task, with a full receipt.
  • The parent bounces back out of Verifying. Merge did not mean done, and now you know.

05 · The difference

Why it beats Jira

The ticket isn’t the start of the work. It’s the output of a cited investigation and a chosen Solution.

Every ticket traces back to evidence

  • In Jira , a ticket begins with a blank field. In Vernais, it begins with a Case file.
  • The Solution came from a root cause. The root cause came from grounded, cited evidence.
  • So every Task carries its lineage: IN-n-T1 → Solution IN-n-S1 → Hypothesis IN-n-H1 → the investigation that found the cause.

One connected surface, not three silos

  • Jira for tickets, a spreadsheet for capacity, and a chat thread for “who’s free?”, all replaced by one board that already knows.
  • The assignee ranking, the schedule, and the gate all read the same graph. No copy-paste, no stale sync.

The work closes the loop

  • A Task that ships unlocks Measure, where the initiative’s Tracking metric is locked as a Baseline and watched.
  • A ticket doesn’t just get marked done. It moves a number you can prove.