Set up your organization

Creating an organization takes a minute. What it sets up decides how every product in it is judged, so it is worth a few more.

What actually happens

Creating an organization asks only who you are and what it is called.

Taiga fills in four answers about your business, generates a set of policies and an approved technology table from them, and drops you on your organization dashboard with a four-item setup checklist. The card goes away once the four are done.

The first item is your policies, and it is first for a reason: the setup is already done when you arrive, using defaults nobody has seen yet. Your job is not to configure anything. It is to check what was configured for you.

The checklist shows you the four answers inline, so you can see what you are about to inherit without opening anything.

The four answers

Answer	What it means
Country	Not a choice today. Taiga is currently offered in one country, so this is fixed until more are added.
Industry	Every industry you operate in. All of them, not just the main one.
Stack	The languages and frameworks you build with. The full list of choices.
Cloud	The clouds you deploy to. Defaults to AWS, so change it if that is not you.

Industry, stack and cloud each take several values, and each needs at least one.

What each answer decides

None of these is decoration. Each one selects different content in the policies:

Answer	Selects
Industry	The regulatory controls that apply to you.
Country	The regulatory regions you fall under, and the regional controls that come with them.
Stack and cloud	Your approved technology table, and the presets in the architecture policy.

Industry decides what you are held to. Each industry you select adds its controls. They combine as a union, so selecting two does not average them or pick the stricter one. It applies both. A company that is both fintech and healthcare gets both sets, and every specification, architecture and security assessment is written against the combination.

That makes it the easiest answer to under-give. Naming only your primary industry produces documents that look complete and quietly omit a second set of controls.

Stack and cloud decide what gets built. Together they become your approved technology table: the reference agents plan against when they choose a language, a framework or a managed service. If your organization has a technology strategy, this is where it becomes enforceable rather than aspirational, and it is the difference between agents proposing what you already run and agents proposing something reasonable that you do not allow.

Cloud also changes the policies themselves rather than just labeling them. Naming a provider gets you that provider’s controls. Choosing Other gets you the provider-agnostic preset instead, which is generic guidance where specific guidance was available. Pick it when it is true, not to defer the decision.

Read the policies, then confirm them

Nine policies are generated, spanning security, data and privacy, risk, how you build, what you build on, and third parties. Policies covers the set and how versioning works.

Underneath them Taiga asks “Do these match your organization?” and offers one button: These look right.

That button is worth understanding rather than clicking past. Every policy is seeded at version 1 the moment the organization is created, so nothing in the product can distinguish “policies exist” from “somebody has read them”. Pressing it is you saying you did. Nothing else can say it for you.

Do this before your first product rather than after. The policies are the standard everything is checked against, and they are far easier to correct while no work depends on them.

Changing an answer later is safe

If something is wrong, Edit tailoring opens the four answers for changing.

Changing them does not quietly rewrite your policies. Taiga shows you what would change first and applies it only when you say so. Anything you edited yourself is kept, and where your wording conflicts with an update you decide which one wins, one section at a time.

The cost of a late correction is elsewhere. It does not retroactively rewrite documents or code already generated from the old answer, so the sooner it is right, the less there is to regenerate.

Your design system shapes output too

The four answers decide what is allowed. Your design standards decide what generated interfaces look like, and they are read from Discovery onward, not only when an initiative is planned in detail.

Taiga seeds a set of standards during onboarding, so something sensible is always in place. Two things are worth doing early:

• Read them, for the same reason as the policies: they are much cheaper to correct before anything is generated against them.
• Link your design-system repository, if you have one. Agents then build against your real components and tokens rather than a description of them, and the difference in quality between the two is large.

What Taiga builds, by default

Taiga writes the products themselves. Whether it also writes their infrastructure code and their CI/CD pipelines is your organization’s call. With CI/CD pipelines off, Taiga writes no CI or deploy workflows at all, and your own pipelines build, test and ship what it produces. The default for both lives in Organization settings, on the What Taiga builds by default card.

Leave both on if Taiga builds the whole delivery path. Turn one off if a platform team in your organization already owns it.

A product inherits the default until someone decides on the product itself. Changing it here therefore changes every product that has not decided for itself, new and existing alike. It is not retroactive: a product picks the new answer up the next time a document is generated or an initiative is planned, and documents and plans produced under the old answer stay as they are.

A product can always disagree: creating one asks which of the two Taiga should build for it.

Each switch changes only its own half, and only the parts of the work that half touches. With infrastructure code off, the architecture describes what the application needs from the host you already run rather than designing one, and plans contain no infrastructure work. With CI/CD pipelines off, no document chooses a pipeline vendor and plans contain no CI or deploy workflows. With either one off, the first initiative gets the product ready to run on what you own: containerization, configuration and a health endpoint, plus whichever half Taiga still builds. The rest of the documents and initiatives are the same.

Where everything lives afterwards

The checklist is a starting point, not the only way in. Policies, your Design System and the Audit Log all sit under Governance in the organization’s navigation, with the tailoring summary above the policies, and they stay there once the checklist is done with.

Where to go next

• Policies for what the nine cover and how versioning works.
• Design system to make generated interfaces look like your product.
• Your first product now that the organization is set up.
• Organizations, factories and products for how settings at this level reach the products underneath.