Your business changes. Your software can keep up.

New-project setup requires specification, user flows, architecture, technology decisions, data flow, threat model, DPIA and risk register. Service Blueprint and Look & Feel are optional. Imported reality documents follow the codebase-analysis workflow.

Applies to

New-project setup

What this does not establish

Publication and review follow the project workflow. Optional documents are not required for every project, and later initiatives use the published context rather than recreating the whole set.

From a published specification, Taiga drafts user journeys with diagrams, decisions and steps. Edit in conversation alongside the document, inspect the changing draft and publish the version that architecture and later planning will use.

Applies to

Published specification and permission to edit project documents

What this does not establish

Draft changes do not affect downstream work until publication. After setup, reopen setup to change the locked document set.

Taiga drafts choices for the overall look, navigation and form conventions, then proposes a combination as one rendered screen. Change individual choices, compare page and form views, and publish the direction that planning and building use.

Applies to

Optional new-project document after specification and User Flows are published

What this does not establish

Imported projects are not offered Look & Feel. Linked customer design systems provide colors for previews with generic components; they do not yet provide their full component set. The broader UI Studio workbench is separate.

Import derives versioned reality documents with file citations, then runs repository scans and an assessment against published policies. The initial backlog waits for that evidence and references the findings and gaps it addresses. Your team can then review and prioritize the work.

Applies to

Choose Import codebase when creating the project, then connect its repository

What this does not establish

Import mode is selected when creating the project. Reality documents describe the code and refresh from it; standing constraints belong in project instructions. A stage with no applicable repository or policies is skipped explicitly. The generated backlog is not proof that the software is correct.

The board groups work into Build, Queue, Todo and Backlog. Taiga plans and builds one initiative at a time per project, using its documents, policies and repository context. Plans can wait for approval, or build on their own. The next queued initiative starts after the preceding pull request merges.

Applies to

Configured project, repository and delivery mode

What this does not establish

Automatic merge must be allowed by the organization and team and respects repository checks and required approvals. An initiative can override the project default within those limits. Merge is separate from deployment, which follows the configured pipeline. Failed or incomplete work does not gain release approval.

Taiga mirrors deployment records and status from connected GitHub repositories. The configured customer pipeline executes deployment and any environment approval steps.

Applies to

Connected GitHub deployment records

What this does not establish

A displayed production deployment is a provider record. It does not by itself verify application health, perform rollback, or establish a Taiga-managed on-call service.

Maintaining groups dependency, secret, code and infrastructure findings into work your team can act on. Fix queues a remediation initiative. Eligible urgent dependency updates can enter the queue automatically. Building and merging follow the configured controls. A fresh scan verifies scanner findings; a new assessment against refreshed documents verifies policy gaps.

Applies to

Linked repository scans and assessments against published policies

What this does not establish

A failed scanner preserves earlier findings. Policies shows cited document gaps and controls breached by findings, with the work addressing them. Unlisted controls are not marked passing. Removing a committed secret does not revoke it; the exposed credential must be rotated separately. Policy evidence does not certify compliance.

Application availability checks require a configured URL. Browser signals require the Taiga beacon to be installed. Monitoring and repository scans answer different questions; missing setup or stale data must remain visible.

Applies to

Configured URL checks; installed beacon for browser signals

What this does not establish

Missing telemetry is not a healthy result. These signals do not imply complete infrastructure observability, incident response or autonomous production remediation.

Microsoft Entra ID connects against a verified organization domain. Google sign-in is available separately. Organization roles govern actions and teams govern project access. Require SSO blocks password sign-in for affected members, with an owner recovery exception.

Applies to

Verified domain and administrator configuration for Entra

What this does not establish

Google sign-in is not a customer-controlled directory. SAML and SCIM provisioning are not offered as current capabilities here.