Tracker reconciliation: the ID Partners objectives tracker against ours

Prepared 2026-08-10. Reconciles PoC_Objectives_Tracker_1.xlsx, supplied by ID Partners, against objectives/tc-objectives.yaml, the eleven demo scenes in section 5 of the master plan, the split export in docs/objective-split.md and the sixteen files in docs/evidence/.

Quoting convention. Cell values are quoted verbatim except that the em dashes in the original have been replaced with a colon or a comma, because pnpm lint:framing fails on em and en dashes anywhere in this repository. No wording has been changed. Every quotation carries its cell reference so the original can be checked.

Provenance of the file, observed

Extracted with openpyxl 3.1.5 and cross checked by unzipping the package and reading the raw XML, so that nothing openpyxl normalises away could hide.

The file was generated by a script or an assistant using openpyxl and then opened and saved once in Excel, eight minutes later. It was produced this morning, which means it predates the split export we are due to send tomorrow under phase 0 of the plan. Nothing in it can have been informed by our tracker.

Searched for and confirmed absent: hidden rows, hidden columns, cell comments or notes, data validation lists, defined names, drawings, text boxes, charts, external links, additional worksheets beyond the three. The package contains only sheet1.xml, sheet2.xml, sheet3.xml, sharedStrings.xml, styles.xml, theme1.xml, calcChain.xml and the two docProps parts. There is no fourth tab and no hidden content. Everything in the file is reported below.

Sheet shapes, observed

Their column headers, verbatim

A1 ID, B1 Objective (verbatim), C1 Domain, D1 DEMO, E1 POC, F1 Demo Evidence Required (verbatim), G1 POC Required (verbatim), H1 Demo Coverage, I1 POC Covered (6 Aug call).

Row 30 holds four formulas: D30 =COUNTIF(D2:D29,"Y"), E30 =COUNTIF(E2:E29,"Y"), H30 =COUNTA(H2:H29), I30 =COUNTA(I2:I29).

Column I is empty on all twenty eight rows. There is no cell content anywhere in I2:I29, so I30 evaluates to zero. The Meeting Notes tab explains why, at A12 to A15: the 6 August call was "logistics/role allocation : it contained almost no technical content, hence the sparse 'POC Covered' column."

Verbatim claims verified against the source

Columns B, F and G are labelled verbatim. I checked them against Agentic IDAM - Trust Controller PoC Objectives - FINAL (2).pdf (in ~/Downloads, text extracted with pdftotext -layout). Spot checks on TC-03, TC-05, TC-08, TC-09, TC-10, TC-11, TC-12, TC-13, TC-14, TC-18, TC-19, TC-25, TC-26, TC-27 and TC-28 all match the source exactly. Their split of the source's single "Vendor Evidence Required" cell into a Demo: line and a PoC: line is faithful, and where the source does not split, they say so explicitly rather than inventing a split. Example, G3:

"[Source does not split this evidence requirement by phase : same text applies to both Demo and PoC.]"

Their transcription is accurate and their annotations are honest. Where the source is internally inconsistent they flag it rather than resolve it silently, at F10:

"[Note: source Phase field says 'Proof of Concept' only, yet the Vendor Evidence Required text still carries a 'Demo:'-labelled line : preserved verbatim; flagging the inconsistency rather than silently resolving it.]"

That is a real inconsistency in CBA's document, at TC-09, and they are right to surface it. Our tracker resolves it silently in favour of the Phase field (phase: poc), which is the defensible reading but is an undeclared assumption on our side.

They have not invented an objective. Rows 2 to 29 are exactly TC-01 to TC-28. There is no row 29a, no TC-29, no sub requirement broken out as its own row.

The headline

Their Demo Coverage column does not assess the demo we are building.

It assesses the six phase walkthrough recorded on the Ralph Demo Phases tab: an agent generates an instance key, a wallet provider attests it, the agent registers as a client at a bank OP, a user delegates authority to the agent as a verifiable credential, the agent performs a delegation token exchange and an agent to agent delegation, calls protected resources, runs access policy, hits a step up for a high value action, and finally the customer revokes the delegation. That is the retired travel scenario. Their own sheet calls it by name three times, at H23, H24 and H25:

"separate from airline demonstration"

Against that walkthrough they score the twenty two demo flagged objectives as four clear yes, ten partial, one not covered, one unclear, and six carrying free text. If that spreadsheet reaches CBA in its current form it is a scorecard against us, authored by our own delivery partner, built from a verbal description of a demo we retired. The remedy is a same day send of the split export and the eleven scenes, not a rebuttal.

The verdicts, transcribed from column H:

Read against the eleven scenes instead, most of those verdicts change. TC-02 and TC-05 are scene 02 and are already verified live. TC-04 is scene 06 with three racing propagation paths and a stopwatch. TC-25 is scene 08. TC-26 is scene 09, which is the enterprise key material answer they say is missing. TC-27 is scene 10. TC-28 has scene 11. None of that was available to Mina when the sheet was written.

Two of their verdicts survive the correction unchanged, and those are the ones that matter. TC-06 stays not covered. TC-01 stays partial for the same reason.

1. What their spreadsheet contains that ours does not

1.1 A required vendor demo artefact that neither party is building: the mock marketplace handoff

This is the most important finding in this document.

Their verdict at H7 is "Not covered : no marketplace/catalogue appears anywhere in this demo." Our master plan, section 8, lists "The Agent Marketplace or Catalogue. ID Partners builds it" under what we are deliberately not building. Our tracker at TC-06 carries the handoff "ID Partners owns the marketplace side of the responsibility model." Their tracker has no owner column and records it as not covered.

So: we have assigned it to ID Partners, ID Partners have recorded that it does not exist, and nobody has written down that they are building one.

Three facts from the source make this expensive rather than tidy.

First, the vendor evidence required at TC-06 (F7, verbatim) is not only a responsibility model:

"Responsibility model; integration pattern; mock marketplace/catalogue Agent registration and Agent Identity Manifest handoff to Trust Controller. Registration request resulting in an Agent Identity Manifest."

That is a live artefact, not a diagram. A registration request that results in a manifest.

Second, TC-06 is the only objective in the whole matrix whose Phase is Enhanced Vendor Demo with no proof of concept phase. Both their E7 (blank) and our phase: vendor-demo agree. There is no second chance at it. If it is not shown on 24 August it is not shown at all.

Third, section 9 of the source, "Suggested Phase Outcomes", names the vendor demo outcome as:

"Shortlist-level confidence on product-native functional fit, architecture fit, deployment model, vendor maturity, core trust lifecycle, mock Agent-to-Agent Identity handoff, and commercial/TCO risk before contract dependency."

The mock Agent to Agent Identity handoff is one of seven named outcomes for the milestone we are delivering. Section 4 of the source also states that the vendor demo "should demonstrate product-native capability using vendor-hosted environments, synthetic data, mock marketplaces, mock authorisation servers, mock policy consumers" (emphasis added), and that it should not require "CBA Marketplace/Catalogue integration". CBA is not asking for their marketplace. CBA is asking for a mock one, from the vendor, at the demo.

TC-01 rides on the same missing piece. Its demo evidence at F2 is "mock marketplace/catalogue registration flow; Agent Identity Manifest schema; event/API handoff to Trust Controller; sample successful and rejected identity workflow outcomes." Our scene 01 delivers the last three of those four from the git side. The first is the gap.

Assessment. Our reading of the scope correction ("ID Partners builds and shows it") is defensible as a commercial split, but it leaves a demo phase only objective with no builder and no confirmed date. Scene 01 already consumes a manifest from git and drives Connect. A thin catalogue front end that lists agents, takes a register request and emits that same manifest is a small piece of work that plugs into the existing scene and closes TC-06 and the front half of TC-01 outright.

1.2 The Acceptance Criteria column, dropped from their sheet and absent from ours

The source objective matrix has six columns: ID, Objective, Domain, Phase, Evidence Level, Vendor Evidence Required, Acceptance Criteria.

Their sheet carries the first six and drops Acceptance Criteria entirely. Our objectives/tc-objectives.yaml has no acceptance criteria field either. We paraphrase acceptance language inside the free text notes on TC-01, TC-03, TC-04, TC-07, TC-18 and TC-27, and nowhere else. Twenty two of twenty eight objectives have their acceptance text nowhere in this repository.

That is the column CBA scores against. Some of its clauses are not implied by the evidence column. Observed examples, quoted from the source PDF:

1.3 Section 8 guardrails and section 9 phase outcomes, in neither tracker

Their sheet stops at the objective matrix. Ours does too. The source carries two further sections that constrain how the objectives are scored.

Section 8, Six Week Scope Guardrails, names the three agent scenarios CBA considers representative:

"mock marketplace Agent registration triggering Agent Identity workflow, token trust check, and Agent suspension triggering identity withdrawal"

Those are scene 01, scene 03 and scene 06. Two of the three are built or building. The first is the gap in 1.1 again, arriving from a third direction.

Section 8 also states, under Design depth, that CBA wishes to "avoid asking vendors to complete detailed CBA-specific design or production build artefacts during the demo or constrained PoC", and under Deferred items confirms the third party ecosystem deferral our plan already records.

1.4 The Ralph Demo Phases tab, which has no counterpart on our side

Six rows plus a footnote. Beyond the coverage mapping already quoted, it contains two judgements about our capability that are worth having in writing, at C3 and C4:

"NOT in the 28 written objectives. This is a genuinely new capability : user-to-agent delegation via Verifiable Credential : richer than a plain OAuth consent screen. Recommend deciding whether to add as a new scored objective or capture as differentiating vendor capability."

"Agent2agent delegation itself: NOT in the 28 written objectives : multi-hop delegation chains aren't named anywhere in the document."

I checked both claims against the source. They are correct. Neither verifiable credential based delegation nor multi hop delegation chains appear in any of the twenty eight objective statements, in any Vendor Evidence Required cell, or in any Acceptance Criteria cell.

The footnote at A8 records an assumption they want confirmed:

"Note: user provided 5 numbered items but said '6 phases' : treated step 3 as two phases (token exchange/agent2agent, then resource call + policy) to reach 6. Confirm this split is correct."

1.5 The Meeting Notes (6 Aug) tab, and four open follow ups

Their record of the role split, at A8 and A9:

"Ralph runs the vendor demo itself and explicitly said he will not produce documents/presentations."

"David/Mina own CBA-integration Q&A and the supporting participant documentation for the session."

Their four open follow ups, at A18 to A23:

1. "Confirm whether 'bank OP' in the demo is a real Ping/Entra test tenant or a demo-only OP : materially affects TC-11 and TC-12."
2. "Confirm who/what the 'wallet provider' attesting the agent's key actually is : affects TC-26, TC-28."
3. "A 'new API that Marco was building' is reportedly live in the upgraded CBA environment : no detail given; flagged as Unclear against TC-09 rather than assumed."
4. "Confirm the demo's step 3 is genuinely two phases (6 total), not five."

Follow up 1 is the highest risk item on their sheet and it is not really a question about the demo. Our own framing rules put "panel reads reference OPs as Raidiam selling an OP" as the highest scoring risk in the demo, and the three treatment labelling convention exists to prevent exactly this. Our delivery partner has already made the wrong inference, in a document, before the demo. The answer is that all seven OPs are packages/op-demo reference implementations that stand in for the customer's authorization server, and every screen labels them as such.

Follow up 3 is unresolved on our side too. I could find no reference to a Marco or to a new API in CLAUDE.md, the master plan, docs/directory-recon.md or the objective split. It needs an answer from Mina, not from us.

1.6 Sub requirements in their verbatim columns with no counterpart in our tracker

Every item below appears in the source and in their sheet, and is absent from objectives/tc-objectives.yaml, from the eleven scene descriptions and from docs/evidence/. I grepped the evidence directory for each term before listing it.

None of these is large. Collectively they are perhaps two days of authoring spread across content we are already writing. The risk is not effort, it is that each is a specific noun a scorer can look for and fail to find.

1.7 Objective text: theirs is verbatim, ours is normalised

Our objective field paraphrases all twenty eight. Mostly harmless, but TC-09 drops a clause. Source:

"dynamic client onboarding or equivalent onboarding for Agent Identities"

Ours: "dynamic client onboarding for Agent Identities." The dropped clause is the one that gives us latitude, so losing it narrows our own objective against us. Where the coverage page renders to CBA, it should carry CBA's wording.

2. Ownership

Their spreadsheet has no owner column. There is no per objective assignment of Raidiam versus ID Partners anywhere in the file. Ownership appears only as free text on the Meeting Notes tab. So there are no line by line ownership disagreements to enumerate, which is itself the finding: the artefact that was supposed to settle who owns what does not carry the field.

Three ownership conflicts are nevertheless observable.

2.1 Documentation: their notes say Raidiam produces none, our tracker assigns Raidiam thirteen

A8: "Ralph runs the vendor demo itself and explicitly said he will not produce documents/presentations." A9: "David/Mina own CBA-integration Q&A and the supporting participant documentation for the session."

Our tracker assigns owner: raidiam with status: evidenced to thirteen objectives, backed by authored documents that already exist: TC-11, TC-13, TC-14, TC-15, TC-16, TC-17, TC-19, TC-20, TC-21 and their content files, plus TC-24 and TC-06 as shared. Fifteen files in docs/evidence/. The master plan also has us delivering a microsite and an eight to twelve minute narrated film.

Both readings cannot hold. Either ID Partners are writing hardening, network architecture, data protection, recovery, observability and deployment model answers right now in parallel with ours, in which case CBA receives two versions of the same security posture and any difference between them is a finding against the vendor, or they are not writing them and believe Raidiam is not either, in which case those objectives arrive blank. Both failure modes are worse than the work.

This needs one sentence of resolution: Raidiam authored the vendor side evidence and here it is, ID Partners own the CBA specific and commercial answers. It is a good news conversation, and it is overdue.

2.2 TC-12, owned by ID Partners in our tracker, marked demo required in theirs

Our tracker: owner: idpartners, with the handoff "David was explicit on 6 August that this belongs in the second presentation, not the vendor demo."

Their sheet: D13 = Y. The source agrees with their sheet: Phase is Both, and the vendor evidence at F13 reads "Demo: overlay architecture, supported integration patterns, compatibility matrix for Ping, Entra, gateways, and APIs, and known limitations."

So a Ping and Entra compatibility matrix is demo phase evidence that CBA asked for, we have written a document for it (content-overlay-compatibility.md), we have assigned presenting it to ID Partners, and ID Partners' own tracker records no owner and their meeting notes do not mention the deferral we attribute to David. Confirm who presents that matrix on 24 August.

2.3 TC-28, wholly ID Partners in our tracker, half of it is our pipeline

Our tracker: owner: idpartners, handoff "SPIFFE and SPIRE integration deferred to ID Partners."

The demo evidence at F29 is "API specification; CI/CD or pipeline registration walkthrough; mock marketplace-to-identity workflow trigger; SPIFFE/SPIRE integration design; mapping of workload attestation outputs ... to Agent Identity and trust metadata." Only the fourth of those five is SPIFFE integration. The API specification and the CI/CD registration walkthrough are the governance as code pipeline in phase 4, which we are building. The mapping table is ours because we build the analogous binding in scene 11.

I am not editing the tracker. Recommending that TC-28 becomes owner: shared with the SPIFFE design alone deferred, because an objective marked entirely someone else's is an objective nobody rehearses.

2.4 A misreading in their sheet worth correcting rather than adopting

H15, on TC-14: "demonstrated in POC via delegation, RAR and Policy". TC-14 is identity and authentication controls for PoC users, services, marketplace integrations, Trust Controller integrations and vendor access, with acceptance criteria "No anonymous or shared access is required" and "privileged access is controlled and auditable". It is about who logs into the environment and how vendor access is controlled. It is not about agent delegation. Our treatment, evidence level content in content-access-controls.md, is the right one. If their sheet goes to CBA with that cell unchanged it answers a different question than the one asked.

Similarly H19 and H20, "Y- logging exists in demo", are thinner than TC-18 and TC-19 require. TC-18 asks for a logging architecture, an event catalogue, correlation identifiers spanning the marketplace and the Trust Controller, and a retention approach. Our scene 07 is a much stronger answer than the one their sheet gives on our behalf.

3. Phase

No disagreements. Twenty eight of twenty eight agree, and both agree with the source.

I checked their D and E flags against our phase field and against the Phase column of the source PDF, objective by objective.

Their D30 and E30 totals evaluate to 22 and 22 respectively.

Evidence levels also agree. I checked our evidence list against the source Evidence Level column for all twenty eight and found no mismatch, including the ones that are easy to get wrong: TC-02 is Demonstrate only, TC-13 is Evidence only, TC-14 is all three, TC-26 is Demonstrate plus Evidence with no Integrate, TC-28 is all three.

One nuance rather than a disagreement. TC-12's phase is Both in all three documents, but our handoff note records a verbal agreement to defer it to the second presentation. That is a schedule decision sitting on top of an agreed phase, and it is the kind of thing that reads as a missing deliverable if the panel has the source in front of them. See 2.2.

4. Expected demonstrations with no scene

Cross referenced against the eleven scenes in section 5 of the master plan.

4.1 Policy authoring and approval controls, TC-08

F9, verbatim: "Demo: policy model; sample policies; allow/deny outcomes; policy authoring and approval controls; source attributes from Agent Identity Manifest or approved Agent metadata." Acceptance: "policy changes are controlled and auditable."

Scene 05 shows five denials, which covers policy model, sample policies and allow or deny outcomes. Authoring and approval controls are the half we have declared out of scope: CLAUDE.md records "Approval and rejection workflow: not in Connect and will not be."

The scope correction is right about the product and wrong about the answer. The governance as code pipeline is policy authoring and approval control: a policy change is a pull request, the approval is the merge, the audit trail is the commit history, and the apply is the enforcement. That is a stronger answer than an in product workflow, and it is already in phase 4. It is currently pointed at TC-01 and TC-07 only. Pointing it at TC-08 as well costs nothing and turns a declared gap into a differentiator.

4.2 Everything else with no scene

5. What we have built that their tracker does not ask for

Not a problem, and mostly upside. Worth knowing which is which.

They flagged two themselves, correctly. Verifiable credential based user to agent delegation, and agent to agent multi hop delegation, appear nowhere in the twenty eight objectives. Their recommendation at C3 is to decide whether to propose them as scored objectives or present them as differentiating capability. That is a good commercial instinct from our partner and it deserves an answer. My view: do not ask CBA to amend a scoring matrix eleven days out. Present both as capability that exceeds the ask, inside scenes that are already scored on other objectives.

Over delivery against a lighter requirement. TC-04 asks only for "logs showing withdrawal propagation; timing or latency measurement." Scene 06 races three propagation mechanisms with an on screen stopwatch. That is well beyond the ask and it directly answers the acceptance clause about stale metadata tolerance, so it is worth keeping and worth calling out as exceeding the requirement rather than merely meeting it. Two of those three mechanisms are separately priceable, so narrate them as capability, not as scope.

Asked for nowhere in the twenty eight. Post quantum signing profiles. TC-26 asks for a key reference model and a rotation approach, not for post quantum readiness. Keep it, show it, do not scope it.

Asked for indirectly and worth reframing. The seven brand heterogeneous estate model and the universe and constellation visualisers are not a named requirement. They serve Strategic architecture fit and Integration fit, which are two of the eight weighted scoring domains named in section 3 of the source, and they are what makes the trust chain legible rather than abstract. Keep, and label as evidence for those domains rather than as an objective.

Effort worth questioning. Nothing rises to stop spending on. The closest is depth of estate modelling beyond what the scenes traverse, since section 8 of the source explicitly says CBA wants to "avoid asking vendors to complete detailed CBA-specific design ... during the demo". Enough estate to make the scenes land, no more.

6. Contradictions with the 6 August call and with the objectives paper

6.1 Their notes say the 6 August call had almost no technical content. Our tracker cites it twice for technical facts

A12 to A14: "This 6 Aug call was logistics/role allocation : it contained almost no technical content."

Our tracker cites that call for two substantive technical positions:

• TC-09 handoff: "Mina confirmed on 6 August that ID Partners has a module that walks the trust chain."
• TC-12 handoff: "David was explicit on 6 August that this belongs in the second presentation, not the vendor demo."

Neither appears in their notes. Their notes instead record, at A21, a different and vaguer TC-09 recollection: "A 'new API that Marco was building' is reportedly live in the upgraded CBA environment : no detail given; flagged as Unclear against TC-09 rather than assumed."

Both of our citations are load bearing. The trust chain module is why TC-09 is owner: idpartners, status: evidenced rather than a gap. The second presentation deferral is why TC-12 is not in the demo. If either recollection is wrong, an objective moves. Confirm both in writing.

6.2 The role split contradicts our delivery plan

Covered at 2.1. Their notes have Raidiam producing no documents or presentations. We are producing fifteen evidence documents, a microsite and a narrated film.

6.3 A real inconsistency inside CBA's own document, which they caught and we did not

TC-09's Phase is Proof of Concept, yet its Vendor Evidence Required cell carries a line prefixed "Demo:". Their F10 preserves it and flags it. Our tracker resolves it silently to phase: poc.

Our resolution is almost certainly right and matches the Evidence Level of Evidence plus Integrate. But the "Demo:" line asks for "integration design, onboarding approach, compatibility evidence, sample configuration, and known constraints", and scene 04 delivers a large part of that incidentally. Cheap insurance: keep TC-09 at poc and note that scene 04 evidences the demo labelled line anyway.

6.4 Nothing in their sheet contradicts the objectives paper

Their transcription is faithful throughout. Their coverage assessments are wrong only because they were made against the wrong demo, which is our failure of communication, not theirs.

7. What to do

Ordered by cost of not doing it.

1. Send the split export and the eleven scenes to David and Mina today. Their coverage column is assessed against the retired scenario. Every hour it stays uncorrected is an hour a wrong scorecard could reach CBA. Ask Mina to overwrite column H rather than authoring a second assessment.
2. Resolve the marketplace question in writing within 48 hours. Either ID Partners confirm a working mock catalogue for 24 August, or we build a thin one that emits the manifest scene 01 already consumes. TC-06 is demo phase only. There is no recovery in the proof of concept.
3. Settle documentation ownership in one sentence. Fifteen evidence documents exist. Tell them, so they neither duplicate nor omit.
4. Answer their four open follow ups directly, especially the bank OP question. Our delivery partner has recorded the exact misreading the three treatment convention exists to prevent.
5. Add the acceptance criteria to objectives/tc-objectives.yaml as a field. Twenty two of twenty eight have their scoring text nowhere in this repository.
6. Close the eleven small sub requirement gaps in 1.6 inside content already being authored.
7. Point the governance as code pipeline at TC-08 as well as TC-01 and TC-07, and stop describing approval workflow as a gap.
8. Reconsider TC-28 as shared rather than wholly ID Partners.

Nothing here changes the architecture, the eleven scenes, the estate model or the phasing. One small build (the catalogue front end), one tracker field, and a set of paragraphs inside documents already in flight.