SPICED · data model · Dan and Dr. Dan
The decisions to make together.
Six calls on the SPICED data model where I want your read before we build further. Each has my lean so you can just react. Reply by number and we are moving.
One-minute orientation
SPICED is the protocol every GTM skill plugs into: each element (S, P, I, CE, D) is a namespace, a shared place where skills write typed values and any agent reads them. A skill is a folder that runs on a deal's calls and CRM.
The one design bet driving everything: a skill measures a deal one of two ways, and the two stay in separate records. Diagnosis is what is true on the deal (writes the SPICED record, feeds the forecast). Technique is how well the rep ran the process on a call (writes a separate per-rep record, feeds coaching). Splitting them keeps a rep from being scored on deal stage.
Full brief: spiced-skills-architecture.pages.dev · Repo and schemas: github.com/justdansmith/spiced
The six decisions
1
Does the two-record split hold at the data-model level?
Deal state lives in spiced.schema.json; per-rep, per-call technique scores live in technique.schema.json, linked only by dealId. Everything downstream inherits this boundary.
My lean: keep them separate. Merging them is what creates unfair rep scoring and blended, untrustworthy numbers.
Your callDoes the split hold, or do you see a reason to unify the records?
2
What is the canonical field set and nullability per namespace?
The field names are the contract, so interop depends on them being right and stable. Today each namespace has a starter set (e.g. Decision: coverageIndex, rolesPresent, threadCount, singleThreadedRisk; Impact: projected and realized).
My lean: a small required core per namespace plus optional extensions, versioned. Required stays tiny so implementations can always populate it.
Your callConfirm or redraw the canonical fields, and mark required vs nullable per namespace.
3
Are the namespaces independent, or a graph with real edges?
Some elements presuppose others (Impact diagnosis assumes Pain was surfaced; Critical Event is Impact under a time constraint). This decides whether the record is a flat set or a graph, which changes how agents reason and how completeness is computed.
My lean: independent for writes, with a small set of documented reference edges rather than hard dependencies.
Your callWhich relationships are real enough to model in the schema?
4
Do index formulas live in the spec, or in the implementation?
Each skill computes an index (coverageIndex weights, impactDiagnosisIndex weights). In-spec formulas make scores comparable across vendors; implementation-defined gives flexibility but loses comparability.
My lean: the spec defines the field plus a reference formula; an implementation may override it, but must disclose that it did.
Your callStandardize the formulas, or only the fields?
5
How do we define completeness, deal health, and where does the forecast live?
Today completeness is simply: each of S, P, I, CE, D has at least one skill writing into it. Deal health and the forecast (prognosis) are richer, and we have not fixed where they sit.
My lean: completeness stays a simple coverage check; deal health is a weighted composite of the namespace indices; prognosis is an agent concern that reads the record, not a spec field.
Your callAgree with that split, or should deal health / prognosis be in the spec?
6
How does SPICED map onto Bowtie and Growth Architecture?
This is where SPICED becomes more than a discovery schema and connects to the broader WbD IP. It is the piece I most need you to lead.
My lean: none yet, this is your domain. My guess is Diagnosis fields map to Bowtie stages and Growth Architecture metrics, but you would know the real structure.
Your callSketch the mapping, or point me at the right starting frame.
How to respond
Fastest path: reply by number in Slack (even "1 yes, 2 mostly, 4 let's talk") and I will fold your calls straight into the schema.
Or grab 30 minutes this week and we work 1, 2, and 6 live, since those unlock the rest.