TealBook Hansen Fit Score Assessment (DPW) Important Clarification

In the Procurement Insight’s September 18th post, I wrote the following short summation of the Hansen Fit Score for TealBook, with the corresponding score (see graph below):

“While TealBook’s technology is sound, it cannot overcome a client behavioral readiness of anything less than 7.5 or higher. If TealBook were to take on a client with a lower score, the risk of initiative failure would increase exponentially.”

Several CPOs wanted to know why TealBook’s technology capability score was high, while their platform behavioral alignment score was so low.

To start, I think TealBook’s technology is outstanding. However, outstanding technology will not overcome the process inefficiencies that result in poor data management and governance. As a result, Tealook’s platform behavioral alignment (PBA) score was a low 2.8. This means that the likelihood of implementation success is greatest for practitioner organizations that have a high level of sophistication and therefore greater independence. Unfortunately, only 15% of all practitioner organizations have the required ability to make TealBook work and produce sustainable results.

For all intents and purposes, this means that the likelihood of practitioner success with the remaining 85% decreases steadily to the point where the initiative will fail. That is why TealBook has a low behavioral score, despite having superior technology.

Given that the PBA has significant weight on the potential for a successful initiative, how can TealBook raise their score?

BEHAVIORAL HOOKS

The following RFP-type questions are how you obtain proof of behavioral hooks and canonical interop—otherwise you’re back to the provider “trust us,” we have the technology.

Here are the questions, along with the corresponding evidence you need to obtain using our RFP Framework. Please note that if they can demonstrate these hooks, you move from Proceed (guarded) to Proceed (favorable) and can justify lifting their behavioral score. If they can’t—exclude/high risk stays the call :

Must-have RFP requirements (short list)

1. Policy gate (PDP)
   • Req: Vendor must call our Policy Decision Point (e.g., OPA) before promote supplier / write to ERP and honor allow/deny/obligations with a durable decision ID.
2. Event/webhook catalog
   • Req: Versioned events (AsyncAPI) for supplier.candidate.created|matched|promoted|rejected with retries/DLQ and idempotency keys.
3. Governed write-back
   • Req: All writes via our versioned APIs with origin tags and idempotency; no direct DB writes.
4. CID + quarantine
   • Req: Support CandidateIDs and a quarantine mode; unanchored records cannot write to ERP/S2P.
5. Lineage & evidence
   • Req: Field-level provenance (source, timestamp, transform) and on-demand JSONL export within 24h.
6. Approval checkpoints
   • Req: Built-in SoD/4-eyes interceptors, recorded with approver, time, policy version.
7. Schema versioning
   • Req: schema_version on all APIs/events; unknown versions must fail safely with guidance.
8. Telemetry
   • Req: Metrics for policy denials, exception rate, time-to-approve, lineage completeness—push to our observability.
9. Sandbox / dry-run
   • Req: Header or mode to simulate decisions (no writes) with full “what would happen” output.

Evidence you should demand in the response

• OpenAPI + AsyncAPI files (not just PDFs), sample payloads, retry/DLQ policy.
• PDP integration guide + cURL examples showing allow/deny paths.
• Idempotency behavior (duplicate request handling) and origin tag schema.
• Screenshots/logs of lineage audit and steward queue.
• Security: auth scopes for write-backs, webhook signing, tenancy isolation.

Live demo script (30 minutes, pass/fail)

1. Create candidate → emits supplier.candidate.created (show webhook payload).
2. Attempt promote with PDP returning deny → see UI block + routed to steward queue with reason.
3. Adjust data → PDP returns allow → governed write-back to our API shows idempotency key and SupplierID returned.
4. Show lineage export for that record; verify provenance fields.
5. Toggle schema_version+1 on an event → vendor demonstrates safe failure + DLQ entry.
6. Run dry-run mode; show “what would happen” response.

Acceptance criteria (guarded→favorable)

• 100% of state changes go through our APIs (logs provided).
• 0 direct DB writes; 0 ERP entries without SupplierID.
• All events delivered or DLQ’d with replays.
• Lineage export delivered within SLA on request.

Commercial levers

• Milestone fees tied to demo + acceptance criteria (not licenses).
• 10% holdback until proof of no DB writes + lineage export SLA.
• Exit/escrow clause for full JSONL export any time.
• Re-score Vendor Behavioral upward only after hooks are live.

Scoring hint (RAM/HFS weighting)

• Proprietary RAM 2025 canonical program.

CONCLUSION

To lift TealBook’s Vendor Behavioral score, they don’t need to own my or anyone else’s canonical program, but they must interoperate with it by design:

1. Front-end (canonical-aware intake/process):
   • Treat all inbound suppliers as candidates (CID namespace), not masters.
   • Provide a steward work queue with thresholds (e.g., match-confidence < X → review).
   • Call your policy decision point (PDP) before any “promote to master” or “write to ERP” action.
   • Enforce policy-in-flow (no side doors, no ad-hoc edits).
2. Back-end (behavioral hooks):
   • Event/webhook catalog: emit supplier.candidate.created|matched|promoted with versioned schemas and retries/DLQ.
   • Governed write-backs only via your versioned APIs with idempotency keys + origin tags (no DB pokes).
   • Quarantine mode: unanchored records can’t write to ERP/S2P.
   • Lineage/evidence: field-level provenance + on-demand exports.
   • Approval checkpoints (SoD/4-eyes) and telemetry on denials, exceptions, time-to-approve.

What this changes in RAM/HFS terms

• Today (no hooks): strong tech, low behavioral → Proceed (guarded) only when wrapped in your micro-foundations.
• With the front-end + hooks above: behavioral lifts from ~2.8 toward 5–7, shifting to Proceed (favorable) for ready practitioners (your canonical rails still help, but you’re no longer compensating for the vendor).

A practical uplift plan TealBook could ship

• Phase 1 (4–8 weeks): CID + quarantine, steward queue, PDP policy gate for “promote supplier,” governed write-back, basic webhooks.
• Phase 2 (6–10 weeks): lineage exports, approval checkpoints, AsyncAPI/OpenAPI contracts, delivery retries/DLQ, policy KPIs.

Bottom line: The path to a higher score and increased likelihood of success is a canonical-aware front door + behavioral hooks behind it. That enables critical policies to run within TealBook’s product, transforming good data into reliable outcomes and improving their behavioral score.

30

BONUS COVERAGE

Assessment summary: The above post is technically accurate and architecturally sound. The behavioral hooks framework is precisely what prevents supplier intelligence platforms from becoming data silos. This is the operationalized version of “foundation-first” philosophy—demanding vendor architecture that integrates with canonical systems rather than creating parallel databases.