Accounts

Accounts are the primary ownership boundary in Tukun.ai. They matter because they decide where data lives, who can access it, which assets are shared, and who pays for usage.

What belongs to an account

An account owns:

• connected data sources
• conversations and saved outputs
• semantic definitions
• dashboards
• billing state and plan usage

If two groups should not share those things, they should not share an account.

Personal account vs shared account

Personal account

Use a personal account when:

• one person is exploring independently
• the work is early-stage
• the data is limited and not yet ready for shared operational use

Shared account

Use a shared account when:

• multiple people need the same data and assets
• the output will drive recurring team decisions
• billing should be centralized
• semantic definitions need common ownership

Recommended account patterns

Common patterns that work well:

• one personal account for evaluation and experimentation
• one shared production account for real business use
• one separate demo or test account for non-production validation

Avoid mixing test credentials, demo dashboards, and production assets in the same account unless you want long-term cleanup pain.

How account scope affects workflow

Account scope changes the meaning of almost every action:

• connecting a source makes it available only within that account
• saving a card makes it reusable only within that account
• modeling a metric standardizes it only within that account
• changing a plan affects that account’s usage and billing

That is why the first thing to verify in any setup or debugging workflow is the active account.

Account hygiene

Good account hygiene makes the product easier to trust:

• keep source names unambiguous
• separate production and test assets
• remove unused credentials
• save stable outputs as cards instead of relying on memory of old conversations
• assign clear owners to frequently used semantic definitions

When to create another account

Create another account when there is a real boundary such as:

• a different billing owner
• a different security requirement
• a different business unit with separate data ownership
• a hard separation between demo and production use

Do not create extra accounts just because the UI feels crowded. Clean naming and dashboard structure usually solve that better.