Multi-Team Use

A Touba project can be owned by several teams: platform, security, data, business, operations, research, or product. In this context, the problem is not only to execute a workflow. It is also to know who owns which part of the contract, which reviews are expected before a sensitive profile, and whether those reviews actually exist.

Multi-team responsibility (TEAM-1) adds an explicit ownership and review-gate artifact. It validates organizational responsibility before project preparation or inspection.

Key point

A touba.ownership.json file grants no runtime permission. It creates no grant, secret, handler, memory scope, agent caller, provider, or resource.

It describes who is responsible and which reviews are expected.

When to Use It

Use an ownership artifact when a Touba project contains elements that touch several responsibilities:

• a tool that calls an external system;
• a production secret;
• a shared memory;
• an agent called by several strategies;
• a trigger that launches execution automatically;
• a local package shared by several teams;
• a prod profile requiring explicit review.

Mental Model

Touba separates three levels:

Level	Example	Runtime authority
Touba contract	.tb, AIR, callable_by, memory scopes	Yes
Runtime wiring	manifest, resource bindings, run plan, lock	Yes depending on artifact
Team responsibility	owners, reviewers, review gates	No

This separation avoids a common mistake: turning organizational approval into technical permission. A review can be mandatory for a prod profile, but it never grants network, a secret, or a handler.

touba.ownership.json File

Minimal syntax:

touba.ownership.json

{
  "ownership_schema_version": "touba-ownership-v1",
  "teams": {
    "team:platform": {
      "display_name": "Platform"
    },
    "team:security": {
      "display_name": "Security"
    }
  },
  "owners": {
    "tool:examples.search/SearchDatasets": ["team:platform"]
  },
  "review_gates": {
    "prod": {
      "requires_review_for": [
        "tool_binding",
        "required_capability",
        "required_secret"
      ],
      "reviewers": ["team:security"]
    }
  },
  "reviews": [
    {
      "review_id": "review:search/security-001",
      "profile": "prod",
      "target_ref": "tool:examples.search/SearchDatasets",
      "reviewer": "team:security",
      "decision": "approved",
      "evidence_ref": "reviews/security-001.md"
    }
  ]
}

Main Fields

Field	Role
ownership_schema_version	artifact version
teams	named teams that can own or review an element
owners	Touba target -> responsible teams
review_gates	rules per profile, for example dev or prod
reviews	explicitly supplied review decisions

Target references must be qualified Touba references, for example:

References

tool:examples.search/SearchDatasets
agent:examples.research/Researcher
strategy:examples.research/RunDailyResearch
memory:examples.research/ResearchNotes
trigger:examples.research/DailyResearch

Prepare with Ownership

To verify a sensitive profile:

Terminal

touba prepare \
  --source src/examples/search.tb \
  --ownership touba.ownership.json \
  --profile prod \
  --mode check

Expected result:

• if required owners and reviews exist, prepare continues validation;
• if a review is missing, prepare refuses with an explicit diagnostic;
• if the artifact contains a forbidden authority field, prepare refuses;
• no handler is launched during prepare.

To make the artifact mandatory:

Terminal

touba prepare \
  --source src/examples/search.tb \
  --ownership touba.ownership.json \
  --require-ownership \
  --profile prod \
  --mode check

Without --require-ownership, the artifact remains optional. With this option, absence becomes a refusal.

Inspect Responsibility

Terminal

touba inspect --ownership touba.ownership.json

inspect displays:

• schema version;
• number of teams;
• number of owners;
• number of review gates;
• number of reviews;
• a readable responsibility graph.

Inspection with several artifacts:

Terminal

touba inspect \
  --air build/touba/project.air.json \
  --manifest touba.manifest.json \
  --resource-bindings touba.resources.json \
  --run-plan touba.run-plan.json \
  --ownership touba.ownership.json

In this view, Touba distinguishes:

• Availability graph: what is declared or imported;
• Authority graph: what can grant execution authority;
• Responsibility graph: owners, review gates, and reviews.

The responsibility graph is displayed with the status not_runtime_authority.

Dev/Prod Example

A dev profile can be flexible:

touba.ownership.json

"review_gates": {
  "dev": {
    "requires_review_for": [],
    "reviewers": []
  }
}

A prod profile can require security review for sensitive elements:

touba.ownership.json

"review_gates": {
  "prod": {
    "requires_review_for": [
      "tool_binding",
      "required_capability",
      "required_secret",
      "memory_scope",
      "trigger_activation"
    ],
    "reviewers": ["team:security"]
  }
}

This difference is a preparation rule. The runtime always applies its own artifacts: AIR, manifest, resource bindings, run plan, secrets, lock, and traces.

Useful Refusals

Situation	Expected refusal
--require-ownership without file	missing ownership
sensitive target without owner	missing owner
required review absent	missing review gate
reviewer not declared	unknown reviewer
grants field in touba.ownership.json	forbidden authority field
secrets field in touba.ownership.json	forbidden authority field
automatic compliance mention	forbidden sensitive field

These refusals are useful: they prevent responsibility, permission, and compliance from being confused.

Technical Scope

Multi-team responsibility makes ownership explicit, verifiable, and inspectable without giving it runtime authority.

SSO, cryptographic review signatures, legal timestamping, official CI, regulatory compliance proof, distributed approval workflows, synchronization with ticketing systems, automatic manifest modification, and Verified / Unverified status are separate organizational and platform layers.