How Taiga works

From a sentence.
To software.

Santa’s team needs to review the evidence, but only Santa can make the final decision. Follow that rule from an idea to a running application. Hiding a button will not be enough.

Scroll to build it Try the example app

Illustrative project · North PoleDeadline: December 24

tai.ga

North Pole, Inc.The ListIllustrative project

LearnDeliverOperate

01Discover

First, the questions you haven’t answered.

Project Specification

Define the project by talking it through. Seven sections to cover, and what you agree becomes the specification.

Discovery excerpt · 3 of 7 sections shown

Topics covered

Project Specification

Draft

1. Vision & Purpose

A decision system for reviewing evidence, making final decisions and preserving their history.

2. Users & Stakeholders

ReviewerAssess evidence

ApproverFinalize; explain overrides

AuditorRead decision history

3. Capabilities

Acceptance criteria0/4

Reviewers can submit an assessment.
Only Santa can finalize a decision.
An override requires a reason.
The decision retains its criteria version.

Welcome to Taiga

Every great product begins as an idea. Let's shape yours.

Tell me about what you want to build.

We need a better way to decide who gets presents.

Who makes the final decision?

Elves review the evidence. Santa has the final say.

What if Santa disagrees with the recommendation?

Record the reason. Keep the criteria version used.

Your team + Taiga

Who assesses the evidence? Who can overrule a recommendation? Discovery turns the conversation into a structured specification.

Describe the outcome. Taiga works through the missing decisions with you.

02Specify

Give the idea a version everyone can build from.

Project Specification

Draft

1. Vision & Purpose

A decision system for reviewing evidence, making final decisions and preserving their history.

2. Users & Stakeholders

ReviewerAssess evidence

ApproverFinalize; explain overrides

AuditorRead decision history

3. Capabilities

Acceptance criteria0/4

Reviewers can submit an assessment.
Only Santa can finalize a decision.
An override requires a reason.
The decision retains its criteria version.

Content in all seven sections.

Published · v1Your team

Your team publishes

Review and publish the specification. Downstream work reads the published version, so the agreed rules have a clear starting point.

A draft stays a draft until you publish it.

03Set the rules

Your organization is already in the room.

North Pole, Inc.Published organization context

Decision servicesTeam instructions

The ListProject knowledge + specification

Inherited by the project

Standards become design inputs

ARCH–02 · Architecture StandardsUse the approved web stack

React + TypeScript

SEC–01 · Security & AccessReuse organization identity

Existing OIDC provider

DATA–03 · Data & PrivacyKeep case data in the approved region

PostgreSQL · eu-central-1

UI–01 · Design standardsUse shared components and tokens

North Pole design system

Your organization → Taiga

Published policies, approved technologies and design standards travel into the project. Architecture and security work are generated against that context.

These are North Pole’s example controls and technology choices, not Taiga defaults.

04User Flows

Separate assessment from finalization.

User FlowsPublished · v2

Overview

Review and finalize a decision

Open a case

Who can finalize?

ReviewerAssess the evidence

SantaFinalize the decision

1Open the case and its evidence.
2Check the signed-in person’s role.
3Keep finalization on Santa’s path.

REQ–04Only Santa can finalize a decision.

Shape the user flow

Reviewers can read the list. Only Santa can finalize a decision.

I have separated assessment from finalization. A reviewer can assess evidence; only Santa reaches the final decision.

Overview and decision flow updated

Your team shapes · Taiga updates

Talk through who can do what. Taiga updates the flow beside the conversation, so your team can review the consequence before publishing it.

Draft changes reach downstream work only after you publish the user flows.

05Look & Feel

See what you are agreeing to.

Look & FeelPublished · v1

The ListDecision workspace

Reviewer

Cases

AMAlex Morgan

RLRobin Lee

SRSam Rivera

CASE–014

Alex Morgan

Community review

Helped organize the community book exchange. Two reviewers recommend approval.

Recommendation: approve

Reviewers assess evidence. Only Santa can finalize a decision.

Keep the evidence and decision together. Make the final authority visible before anyone acts.

Taiga proposes · Your team chooses

Taiga proposes a coherent direction. Compare the look, navigation and forms in one composed screen. The published choice becomes context for the build.

Optional for new projects. Linked customer design systems currently ground colors; this is an illustrative composed interface.

06Design

Every technical choice needs a reason.

The List · example application architecture

Review workspaceReact + TypeScript

Organization identityExisting OIDC provider

The List APIChecks who can record decisions

Cases & decisionsPostgreSQL · approved region

Decision historyActor + reason + criteria version

Authenticated requestAuthorize, then writePreserve the decision

Threat: a reviewer calls the finalization endpoint directly.Control: verify the approver role on the server.

SpecificationUser flowsArchitectureTechnology decisionsData flowDPIAThreat modelRisk registerService blueprintOptionalLook & FeelOptional

Taiga drafts · Your team reviews

Generate and review the supporting documents. User flows shape the architecture; approved technology shapes the stack; data flows inform the security work.

Documents are generated individually after publication. Changed assumptions need review and regeneration.

07Plan

Choose what happens next.

Example queue · foundations and identity already delivered

RunningOne active initiative per project

Build1

INIT–04Decision workflow
REQ–04 · Specification v1
Planning

Queue1

INIT–05Decision history
Data & Privacy · Risk register

Todo0

Nothing here yet

Backlog0

Nothing here yet

Build on its own · enabledMerge on its own · required review applies

Implementation plan · v1

Selected initiative

Decision workflow

REQ–04

01Enforce authority in the API
02Connect the review workspace
03Verify denied and allowed requests

Your team prioritizes · Taiga plans

Put the next initiative in the queue. Taiga plans it against the published documents, then builds under your project settings. Your team can inspect the plan and its source references.

Connect the repository and environment first. The next queued initiative starts after the previous pull request merges.

08Build

Now the plan becomes a change in your repository.

north-pole/the-listfeat/decision-workflow

Implementation plan · v1

Decision workflow

REQ–04Only Santa can finalize a decision.

api/decisions.ts

ui/DecisionPanel.tsx

tests/decisions.test.ts

api/decisions.ts

Illustrative implementation excerpt

1async function finalize(actor, decision) {async function finalize(actor, decision) {
2  await validateAssessment(decision);  await validateAssessment(decision);
3  requireOverrideReason(decision);  requireOverrideReason(decision);
4  return saveDecision({  return saveDecision({
5    ...decision,    ...decision,
6    criteriaVersion: 'v1',    criteriaVersion: 'v1',
7    decidedBy: actor.id    decidedBy: actor.id
8  });  });
9}}

Building · decision workflow

Taiga implements

Taiga implements the published plan in your repository. The permission rule becomes acceptance criteria for the API, the interface and the tests.

Automatic build is enabled in this example. Your project can require plan approval instead.

09Verify

A reviewer tries The List’s API.

Before correctionFAIL

reviewer cannot finalize a decision

Expected 403 ForbiddenReceived 200 OK

The UI hid the action. The API still accepted it.

requireRole

Add the role check to the endpoint. Run the test again.

After correctionPASS

reviewer cannot finalize a decision

Expected 403 ForbiddenReceived 403 Forbidden

REQ–04

Reviewer request rejected
Approver request accepted
Override reason required
Criteria version retained

Taiga checks and corrects

A negative permission test exposes a missing server check. Taiga corrects the implementation and runs the checks again before review.

Illustrative test sequence. Passing these sample checks is not a production-readiness claim.

10Review

A change you can inspect before it ships.

Pull request #12 · Example

north-pole/the-listfeat/decision-workflow

Enforce decision authority

+ role check + reason validation + decision history

Example checks passedRequired human review approved

REQ–04Only Santa can finalize a decision.

Your team

Review satisfied → automatic mergeNeeds work → correct → recheck

Your team decides

This project permits automatic merging after its required human review. Taiga waits for repository checks and approvals; your organization sets the limits.

Organization and team limits govern automation. Required repository checks and reviews are never bypassed.

11Release

Follow the commit into the running system.

Example delivery pipeline

MergeReviewed commit
Build & checkVersioned artifact
DeployChosen environment
Runtime checkSign-in + decision path

Example environment

The List is running

Try the decision flow in the local example below.

REQ–04

This example pipeline retains a previous release for rollback.

Your pipeline deploys · Taiga tracks

Your configured pipeline builds and deploys the merged change. Taiga tracks connected GitHub deployments against the project’s environments.

Configure runtime checks and rollback in that pipeline.

The result · Try it

That sentence has a working answer.

Open a case as a reviewer. See who can finalize it. Switch to Santa and record a decision.

Cases

CASE–014

Alex Morgan

Awaiting decision

Community review

Helped organize the community book exchange. Two reviewers recommend approval.

Recommendation: approveCriteria v1

Final decision

Reviewers assess evidence. Only Santa can finalize a decision.

Decision history

No final decision yet.

REQ–04

Browser-only demonstration · fictional data · no backend · resets on refresh

North Pole and The List are fictional. The workflow follows current Taiga capabilities; the records and results illustrate an example delivery.

Keep watching in Taiga

After release: connect the app URL for availability checks. Add the beacon for browser experience signals.

New environment · baseline learning

Use runtime signals to decide what to work on next.

AvailabilityRespondingSample URL checks · production

ExperienceLearning baselineThe beacon is receiving samples. More traffic is needed for a baseline.

API errorsWaiting for enough API callsInstall the browser beacon to collect experience signals.

p95Waiting for enough API callsInstall the browser beacon to collect experience signals.

Response time184 ms

Illustrative 30-day history

Illustrative records and measurements. No live systems are connected.