TC-22 Support, operating model and vendor enablement

On what is claimed here. Where this document describes the demonstration, it states what the Enhanced Vendor Demo of 24 August 2026 is built to prove, not what has already been built, recorded or verified. Status for every scene is tracked in objectives/tc-objectives.yaml.

1. What CBA asked for

Support, operating model and vendor enablement for implementation and BAU transition.

2. Why this document is a frame

Support is a contracted service, and the contract is with ID Partners as reseller. The hours, targets, escalation routes and enablement scope are theirs to state and CBA's to agree. Raidiam should not, and does not, state them here. What follows is the structure the answer should take and the questions whose answers complete it, so David and Mina begin with a worklist rather than a blank page.

No commercial terms appear in this document. Commercials are in content-commercial.md, and are likewise ID Partners' to state.

3. The three party operating model

The line that matters: CBA owns the decisions, ID Partners owns the service, Raidiam owns the product. A question about whether an agent should be approved is not a support ticket. A question about why a resolution failed is.

4. Support flow

   CBA identity platform team
            │
            │  first point of contact
            ▼
   ID PARTNERS  service desk and engineering
            │
            │  escalation for platform defects and
            │  product behaviour
            ▼
   RAIDIAM  engineering

The single point of contact property is the reason for the reseller model. CBA should not have to decide whether a fault is a Ping mapping problem, a bridge problem or a platform problem before it can raise it. ID Partners triages.

5. What each phase needs

Enhanced Vendor Demo, 24 August 2026. No support model applies. The environment is vendor hosted, synthetic and carries no contract dependency. Support during the demonstration is the project team.

Formal Proof of Concept. ID Partners leads. What is needed before it starts: named contacts on each side, an agreed route for raising issues, an agreed severity model, and a shared understanding of who holds the environment. A Proof of Concept without a named owner for the environment is a Proof of Concept that decays between sessions.

Implementation. Roles, responsibilities and the transition plan into business as usual, including which CBA team takes operational ownership and what they need to be able to do unaided.

Business as usual. The steady state service, with the questions in section 7 answered.

6. Enablement: what CBA's team must be able to do unaided

The transition to business as usual succeeds when the CBA identity platform team can do the following without ID Partners or Raidiam in the room. This list is the enablement scope, and it should be worked backwards from.

1. Onboard a new Agent Identity end to end, through the pipeline, including granting the capability roles.
2. Change a capability envelope and confirm the change reached a consumer.
3. Suspend and withdraw an agent, and confirm withdrawal has reached every propagation path.
4. Investigate a refusal: distinguish "no chain" from "no capability" from "envelope exceeded" from "mark not active" (content-observability.md, section 7).
5. Rotate a signing key.
6. Rebuild the environment from the declaration and verify it (content-recovery.md).
7. Onboard a new consuming authorization server.
8. Read the change history and answer an audit question from it.

Every item on that list is demonstrated in one of the eleven scenes, which is a deliberate property of the demonstration design: the demonstration doubles as the enablement curriculum.

7. Questions ID Partners must answer

Service

1. Hours of cover, and whether they are in region.
2. Severity model and response targets by severity.
3. Escalation path and the trigger for escalation to Raidiam engineering.
4. Named contacts on each side, and the route for raising an issue.
5. Incident and outage notification commitments, and who notifies whom.
6. Change and release notification: how CBA learns a platform release is coming and what regression testing is expected.

Delivery and transition

1. Who delivers the Formal Proof of Concept, in what roles, and where they sit.
2. The business as usual transition criteria: what has to be true before CBA's team owns it.
3. What documentation CBA receives, and whether it includes the integration design and the runbooks.
4. Training and enablement scope against the section 6 list, and its format.

Environment and access

1. Who provisions and owns non production environments.
2. Whether CBA staff get hands on access to the platform, and when. This is currently an open item: the working assumption for the Enhanced Vendor Demo is demonstration services only, with no platform logins for CBA, unless ID Partners decides otherwise.
3. Vendor access to CBA environments: named individuals, duration, approval route.

Exit

1. Exit and transition assistance, and what CBA leaves with. Worth noting the technical position is strong here: the declared state of the entire federation lives in a git repository CBA can own, and the platform API is documented, so portability is a property of the design rather than a contractual concession (content-recovery.md, content-data-protection.md).

8. Status

Not stated, by design. Owned by ID Partners. This document is the brief.