Module 7: Prescribing Interventions

7.1 The Intervention CatalogCore

The SDC ecosystem provides discrete capabilities that map to specific maturity gaps.

sdcgovernance is a production library on PyPI (Apache 2.0) implementing 24 international standards from 6 standards bodies (W3C, OASIS, OMG, ISO, IETF, IANA). It provides two interfaces: Python API and MCP server (raw JSON-RPC 2.0, no SDK dependency). Any AI agent that speaks MCP gets deterministic governance. The XACML TC Chair has reviewed the implementation. 226 tests pass in 0.27 seconds. Full docs: semanticdatacharter.com/governance.html. Architecture visualization: semanticdatacharter.com/stack.html.

When you read a Maturity Map report, the recommendations write themselves. A client at Level 1 Schema Integrity needs introspection + assembly. A client at Level 2 Provenance needs the common audit layer. Etc.

7.2 The Three Deployment OptionsCore

SDCforSMB (most cases)

• Single-tenant, self-installed Django app over SDC Agents SMB
• Browser UI for non-technical users
• Wallet-based connection to SDCStudio for component minting
• Lightweight stack: PostgreSQL + Fuseki
• Best for: 1-50 person businesses, 1-5 datasources, single physical location

Recommend SDCforSMB when: The client has a small team, wants to run things themselves, and trusts a practitioner for setup and occasional support.

SDCStudio SaaS (full)

• Multi-tenant hosted platform
• Full assembly authoring UI
• Federated component registry
• Enterprise integrations (SSO, SCIM, audit export)

Recommend SDCStudio SaaS when: The client has 50+ employees, multiple business units, or needs to share components across organizations.

Sovereign deployment

• On-prem or sovereign cloud
• Air-gappable
• Local component minting

Recommend Sovereign when: Regulatory or geopolitical requirements prohibit data leaving the premises. Healthcare under strict regional rules, defense, classified work, certain financial sectors.

All generated applications look the same

Regardless of which deployment option the client chooses, the generated applications are identical in appearance and behavior. The UI, the data entry forms, the validation rules, the semantic constraints - all generated from the same SDC data model. The only difference is where the application runs and which graph database backs it.

7.3 When SDC Is Not the AnswerCore

7.4 Sequencing InterventionsCore

The floor constraint principle dictates the sequence. Always fix the foundational dimensions before the derived ones.

Standard sequence:

1. Schema Integrity first — without a schema, nothing else can be enforced. Run introspection, review the assembly, deploy the generated validators.
2. Constraint Enforcement second — once the schema exists, attach the rules. Schematron + SHACL go on top of the schema from step 1.
3. Semantic Identity third — assign CUID2 identifiers to existing entities via the catalog toolset. This is when SDCStudio wallet usage starts.
4. Provenance fourth — turn on audit logging. The audit layer was deployed in step 1 but unused; now it has things to audit.
5. Interoperability fifth — once the data is identified, constrained, and provenanced, exporting to JSON-LD is mechanical.
6. Governance last — governance over a stable foundation is straightforward. Governance over chaos is impossible.

Common mistake: clients want to start with Governance because it sounds executive. Resist. A governance program over a Level 1 schema is a paperwork exercise.

7.5 Pricing the SequenceIntermediate

Each step is a billable engagement. Standard rough scoping for a first engagement in a new vertical:

The hours and fees above describe engagement #1 in a new vertical — when you have no reusable components and you are doing the domain-modeling work for the first time. This is the highest-effort, highest-learning, lowest-margin engagement you will ever do in that vertical. It is also the most important one, because everything that follows compounds off it.

Read the next section before pricing engagement #2 or beyond.

7.6 The Compounding Cost CurveAdvanced

This is the section practitioners come back to most often after their first year in practice. It explains why the fee table above is the starting picture, not the steady state.

Your costs drop. The client's value does not.

The first time you onboard a small mental health practice, you do real component modeling work. You mint TherapySession, GroupTherapyEnrollment, InsuranceAuthorization, PHIRedaction, SlidingScalePayment, and a dozen others. Your Schema + Identity phase is 60-80 hours of practitioner labor.

The second mental health practice has substantially the same data shapes. The components you minted for client #1 are already in the catalog, free to deploy, and bring their constraints, validators, and identifiers with them. Your Schema + Identity phase for client #2 is 30-40 hours.

By client #5 in the same vertical, you are at 15-20 hours. By client #10, you are at 8-12 hours of practitioner labor for an engagement that the client still perceives as a custom-built bespoke application — because it is. The application is bespoke to their data. The components are reused; the deployment is not.

The crucial pricing rule: Do not pass your cost reduction through to the client as a price reduction. Pass your experience through as a value increase.

A practitioner who charges client #5 $30,000 for "the same engagement" delivers in 15 hours instead of 75 hours. The hourly equivalent is $2,000/hour. A practitioner who instead charges client #5 $15,000 because "it was easier" leaves 50% of the compounding on the table — and trains the vertical to expect rock-bottom prices.

Both practitioners deliver an identical bespoke application to client #5. The difference is whether they captured the value of the component library they already paid to build.

The practitioner mindset shift

Coming from hourly consulting, the instinct is "I should charge for the hours I worked." That instinct is wrong here. What you charge for is:

• The bespoke application running on the client's infrastructure
• The years of vertical knowledge encoded in your component library
• The fact that the client cannot get this from anyone else who is not also paying you for the time it took to build the library

The library is your capital. Capital earns returns. Hours earn wages. Choose returns.

When to discount and when not to

Legitimate reasons to discount engagement #5:

• The client is a charity or has compelling cause-related circumstances
• The client agrees to be a public case study
• The client is in a sub-vertical you want to test before committing

Bad reasons to discount engagement #5:

• "It was easier than the first one"
• "I felt guilty charging the same for less work"
• "The client said the price was high"
• "The component reuse was so high I felt like I wasn't doing anything"

The middle reasons are the ones that quietly destroy practitioner economics. Catch yourself making them.

7.7 The Schema-Change Stewardship ProductAdvanced

Most practitioners coming from project-based consulting underestimate this section. It is the most economically important page in the curriculum. Read it twice.

What schema change stewardship is

A client's data does not stand still. A new field is added to their CRM. A new partner integration requires a new datasource. A regulatory update changes what they need to capture. A business line is added. A merger brings in new systems. A product launch creates new entity types.

In traditional consulting, each of these triggers friction: scope conversation, engagement letter, project plan, deliverable, invoice. The transaction cost dwarfs the work itself, so practitioners typically eat the small changes for relationship reasons and only invoice for the big ones.

In the SDC ecosystem, each of these is a touch. A touch is not a project. It is a 30-minute to 4-hour cycle:

1. Remote introspection of the changed datasource (15-30 minutes)
2. Delta review — what new components, if any, need to be minted (5-15 minutes)
3. Mint the new components via SDCStudio (5 minutes; usually under $20 of wallet cost)
4. Download the updated data model and application bundle (automatic, 1-2 minutes)
5. Import the new app and regenerate the UI bindings by asking the LLM (10-30 minutes)
6. Deploy the redeployed application to the client's infrastructure (15 minutes)

Total practitioner labor: 30 minutes to 4 hours depending on complexity. Most touches are at the lower end. The deliverable is a redeployed bespoke application, working in production the same business day.

You bill per touch, not per hour.

Per-touch pricing

These are starting points. Establish per-touch pricing in writing during the original engagement, not after the first change request. A per-touch price list in the original proposal is what makes the steward relationship sustainable. Without it, every change request becomes a scope negotiation.

How to introduce the touch model to a client

Most clients have never been offered this model. Their experience is: "every change is a project, every project is painful, so we postpone changes until they are unavoidable."

The touch model is the opposite: every change is a routine maintenance event, billed per occurrence, that takes hours instead of weeks. The first time a client experiences a same-day schema change in production, they will tell every peer they know. This is the strongest organic referral mechanism in the entire program.

Recommended client framing: "Your data will change. When it does, you call me, I touch the system, you have a redeployed application by end of day. Each touch is billed at our agreed price list. There is no minimum and no monthly commitment. You pay for changes when you need them, not on a calendar. And — this is the part nobody else offers — you will never face a forced software upgrade and you will never have to migrate your data. The application and the data live in your environment, on your hardware, on your timeline, indefinitely."

This is a vastly better deal for the client than a SaaS subscription that bills monthly whether or not anything changed, forces upgrades on the vendor's schedule, and risks data loss on every migration. It is also a vastly better deal for you than a managed services retainer where you are on the hook regardless of touch volume. The "no forced upgrades, no migrations" promise is the one clients quote back to their peers — it is the strongest organic referral mechanism in the program.

Putting axis 1 and axis 2 together

A practitioner with 20 clients in one vertical, averaging 6 touches per year per client at an average $2,200 per touch, is generating $264,000/year of recurring revenue from touches alone on roughly 120 hours of total labor (6 hours per touch average, often less). That is on top of new engagement revenue from continuing to onboard clients.

This is the actual product. The Maturity Map is the diagnostic. The bespoke application is the deliverable. The per-touch stewardship is the business.

What you're delivering in market terms: a governed context graph

When you present to a client's CTO or data leadership, frame the deliverable in the vocabulary they are hearing from their vendors and conferences. You are not delivering "a Django app with some schemas." You are delivering:

• A context graph - a live knowledge graph (RDF/OWL/SHACL) that grows with every component you mint and every model you publish. The graph contains not just the data structure but the relationships, the vocabulary bindings, and the governance rules.
• Structural decision traces - workflow state machines, attestation authority, and provenance chains that are part of the graph, not logged separately. Every decision is queryable: who authorized it, under what authority, what the state of the data was at the moment of the decision.
• Deterministic governance - not dashboards, not after-the-fact alerts, not compliance documentation. Governance that is structurally bound to the payload and travels with the data wherever it goes.

This framing matters because "context graph" is the current market term for what SDC has been producing for years. Using the vocabulary your client's CTO is hearing from Gartner, McKinsey, and Foundation Capital positions you as the practitioner who can actually deliver what those analysts are describing - not as an afterthought or a multi-year initiative, but as an intrinsic output of the modeling work you are already doing.

Execution handoff: from modeling to runtime enforcement

SDC models define what should happen - the legitimate workflow transitions, the attestation authority, the provenance requirements. sdcgovernance enforces these rules at runtime. It reads the governance components from the DMType root slots in the data model and validates the governance content in the XML instance against those definitions.

The enforcement architecture:

• sdcvalidator handles structural validation: does the instance conform to the XSD schema? Single-pass. Deterministic. Pass/fail.
• sdcgovernance handles governance advisory: is the workflow transition legitimate? Is the attestation valid? Is the provenance chain intact? Does the decision table PERMIT this action? Returns OASIS XACML decisions (PERMIT/DENY/INDETERMINATE/NOT_APPLICABLE) with hash-chained tamper-evident receipts.
• Both libraries are independent. No hook, no chaining. Agents call each one separately, at different points in a workflow, in whatever order the operational logic requires.
• Both expose MCP servers. Any AI agent that speaks MCP gets deterministic validation and governance without importing a Python library.

What this means for practitioners:

• When you model workflow, attestation, provenance, and party/role components in SDCStudio, you are building executable governance contracts that sdcgovernance enforces at runtime. Not documentation. Not aspirational policy. Deterministic enforcement.
• The governance templates in the ProvGov library (workflow state machines, DPV retention policies, DMN decision tables) create the governance components that sdcgovernance validates. Upload the template, SDCStudio creates the components, sdcgovernance enforces them.
• pip install sdcgovernance gives any client system governance advisory capabilities via Python API or MCP server. No middleware. No platform dependency. The governance IS in the data.
• sdcgovernance advises. The agent decides what happens after the decision. The operational response to DENY or INDETERMINATE is the customer's business logic - sdcgovernance has no opinion about what happens after it issues a decision.

This is the difference between governance that is described and governance that is enforced. Your models define the governance. sdcgovernance enforces it. Every decision produces a receipt.

Emerging: Trusted Value Framework. The Maturity Map measures structural state. A complementary framework (DTRM, developed by an NHS CDAO) evaluates whether organizational system conditions can convert that structural capability into sustained value. Combined: SDC measures "can the data be trusted," DTRM measures "can the organization act on trusted data," and the economic model prices the gap. This integration is under active development. Practitioners should be aware of it as context for client conversations but should not represent it as commercially available until formal terms are established (DTRM is CC BY-ND licensed; commercial use requires separate permission from the author).