Module 8: Deployment with SDC Agents SMB

Learning Objectives

• Install and configure SDC Agents SMB on a client host or your own laptop.
• Write and validate sdc-agents.yaml for a client engagement.
• Connect each supported datasource type.
• Run a pipeline and interpret the introspection results.
• Walk an assembly through the human review gate before anything billable happens.
• Generate the client application in SDCStudio and deploy it.
• Establish ongoing monitoring and maintenance habits.

What changed

Earlier versions of this module taught SDCforSMB, a browser wrapper around these same agents. That project is retired. The agents it wrapped are the product, and you drive them directly, which is both less to install and less to explain to a client. Everything the wizard did, you now do in a config file and four commands.

8.1 System RequirementsCore

Minimum

• Linux, macOS, or Windows with WSL2
• Python 3.10+
• 4 vCPU, 8 GB RAM, 20 GB disk
• Ollama running locally, for the LLM-assisted steps
• Outbound HTTPS to SDCStudio for catalog lookups, assembly, and validation

Recommended for a client host

• 8 vCPU, 16 GB RAM, 100 GB disk, so larger models run comfortably
• A dedicated service account with read-only credentials to each datasource
• Backups of the working directory, which holds the config, audit log, and cached introspections

No Docker required. This is a Python package and a local LLM. A client who balks at running a container stack will usually accept a single command-line tool on one machine.

Not supported

Air-gapped environments. Assembly and validation call SDCStudio over HTTPS. Use Sovereign deployment for those, per Module 7.

8.2 InstallationCore

# Core install
pip install sdc-agents-smb

# Add only the datasource connectors the client actually needs
pip install "sdc-agents-smb[notion]"
pip install "sdc-agents-smb[sheets]"
pip install "sdc-agents-smb[airtable]"

# Confirm the install and see the agent inventory
sdc-agents info

sdc-agents info prints the configuration summary and the agents available to you. Run it first on any machine you did not set up yourself; it is the fastest way to find out what a client's environment is actually missing.

SQL, CSV, JSON, and MongoDB support ship in the core package. Notion, Google Sheets, and Airtable load as ToolsetHub plugins, which is why they are separate extras. Install what the engagement needs and nothing else.

8.3 ConfigurationCore

Configuration lives in sdc-agents.yaml. The old onboarding wizard existed to write this file for you; writing it yourself takes about ten minutes and leaves you able to explain every line to the client, which matters when they ask what the tool is reaching out to.

The five things it must establish, in the same order the wizard asked for them:

1. SDCStudio connection: base URL and the client's API key. This is what the catalog, assembly, and validation calls authenticate with, and what their credit balance is drawn from.
2. Ollama configuration: URL (default http://localhost:11434) and model. The LLM assists mapping suggestions and datasource descriptions. It never sees the client's rows unless you configure it to.
3. Datasources: one entry per source, with a read-only credential. See 8.4.
4. Distribution targets: where validated artifacts are routed. Fuseki, Neo4j, a REST endpoint, or the filesystem.
5. Notifications (optional): Slack webhook, Telegram bot, or SMTP for pipeline completion and drift alerts. Skip it for a laptop install; set it up on a client host.

# Check the file before you run anything against client data
sdc-agents validate-config

Run validate-config after every edit. It is faster than discovering a bad credential halfway through a pipeline in front of the client.

8.4 Connecting Each Datasource TypeCore

CSV: Path to a directory of CSV files. Each file is discovered and introspected.

SQL (PostgreSQL/MySQL): Connection string. Use a read-only role. The introspection tools never issue writes.

SQLite: File path. Often the simplest demo target.

JSON: Path to a file or directory. Nested structures are flattened during introspection with dotted-path column names.

MongoDB: Connection URI plus database name. Collections are introspected as logical tables.

Notion: Integration token plus workspace. Database properties, relations, rollups, and select options are read. Pages are not.

Google Sheets: Service account JSON. Each sheet is a separate datasource.

Airtable: API key plus base ID. Tables are introspected with field types, linked records, and formula fields.

Privacy guarantee: Credentials stay in the client's own config and are redacted from audit logs. Introspection results are metadata and representative samples, not a copy of the datasource. The agents hold read-only access and never write back to a client system.

The last three are the ones that win SMB engagements. A firm running on Airtable and a Google Sheet does not think of itself as having a database, and showing that those are introspectable on the same footing as PostgreSQL reframes the conversation.

8.5 Running a PipelineCore

A pipeline chains the agents into one run: introspect the datasource, discover matching catalog components, propose an assembly, and stop at the review gate. Seven templates ship with the package.

# See what templates are available, and what one of them does
sdc-agents pipeline list
sdc-agents pipeline show healthcare-csv

# Run one against a configured datasource
sdc-agents pipeline run healthcare-csv -p datasource=patients

Introspection produces 13 fields of standardized analysis for every column:

Anomaly flags are the most useful output for assessment work. They surface things like:

• mixed_types - values in the column have inconsistent types
• unparseable_dates - date column with unparseable values
• near_duplicate_identifier - column looks like an identifier but has duplicates
• format_drift - formats vary within the column
• outlier_count - statistical outliers detected

Each flag is direct evidence for a Maturity Map dimension. Capture the output for the report.

Annotations persist. Use sdc-agents annotate add to record what a column really means when the client tells you, and sdc-agents annotate list to review. Annotations merge into future introspections, so the second engagement with a client starts from what you learned in the first.

8.6 Assembly Review WorkflowIntermediate

The pipeline stops before it spends anything. Nothing billable happens without a human approving it, and that gate is the part of the tool you should show a client first.

sdc-agents assembly list-pending
sdc-agents assembly review <manifest-id>
sdc-agents assembly approve <manifest-id>   # or: reject

The review manifest shows:

• Reuse count (free) - components matched to existing catalog entries
• Mint count (billable) - new components that will draw down the wallet
• Estimated cost - wallet impact in credits
• Wallet balance - current balance, so you can confirm before approving
• Component list - proposed name, signature, and source columns for each

Review carefully. Reject and re-run if something was mislabeled; a rejected assembly costs nothing. Approval mints the new components and binds them to the manifest.

Reuse is the number that matters. A high reuse count means the client's data is being described in components someone already defined and published, which is the entire economic argument you made in Module 7. A run that mints everything fresh is a signal to look harder at the catalog before approving.

Best practice: Run the first assembly in front of the client during Session 2 of the engagement. Watching their data become identified components is the moment the framework becomes real to them.

8.7 Generated Application DeploymentIntermediate

Once an assembly is approved and the data model is published, the client application is generated in SDCStudio. Application generation is an SDCStudio function, not an agent one: you approve the assembly at the command line, then generate the app from the SDCStudio web interface.

How the pipeline works

1. You approve the assembly manifest with sdc-agents assembly approve
2. The data model is finished and published in SDCStudio
3. SDCStudio generates the application bundle (app with database, API, validation, audit logging)
4. You download the bundle and deploy it on the client's host

What the generated bundle includes

• Validators (XSD 1.1 + Schematron + SHACL)
• REST and JSON-LD endpoints
• Audit log integration
• Optional UI scaffold
• Context graph outputs (RDF/OWL/SHACL) with governance components structurally present

Separately from the generated app, the Distribution agent routes validated artifacts to where the client will actually query them, which you configured in 8.3:

# Artifacts land in Fuseki, Neo4j, a REST endpoint, or the filesystem,
# as configured. The pipeline handles this on approved runs.
sdc-agents pipeline run <template> -p datasource=<name>

Walk the client through the first deployment. Demonstrate that the validators reject bad data and accept good data. This is the closing moment of the implementation engagement.

8.8 Ongoing MaintenanceCore

Two capabilities carry the maintenance story, and both are worth selling as part of the engagement rather than leaving the client to discover.

Scheduling. sdc-agents schedule run starts a cron-driven scheduler in the foreground; schedule list shows what is configured and schedule trigger fires one job on demand. On a client host, run it under systemd so it survives a reboot.

Drift detection. Each introspection is compared against the cached previous one, and changes to the datasource structure raise an alert. This is what turns a one-off assessment into a standing relationship: when the client's system changes, you hear about it.

# Evidence for the client, from the audit and lineage logs
sdc-agents compliance report --last 30d --format pdf -o atlas-legal-q1.pdf
sdc-agents audit show

Tell the client to expect:

Set a calendar reminder before you leave the engagement. Clients who do not look at the system for 6 months will not look at it ever.

Module 8 Lab

Continuing with Atlas Legal: You are standing up SDC Agents SMB for Atlas Legal. The sample CSV in lab/sample_csv/ simulates their Clio client export. You are building on your own laptop what will eventually run on a $2,000 Linux box in Dana Okafor's office.

Install sdc-agents-smb on your own laptop. Write an sdc-agents.yaml with a CSV datasource pointing at the provided sample, and get sdc-agents validate-config to pass. Run a pipeline. Review the pending assembly and approve a small one using the demo SDCStudio credentials. Generate an application from SDCStudio against the published model and deploy the bundle locally. Submit:

1. Your sdc-agents.yaml, with credentials redacted, and the passing validate-config output
2. The introspection output, including at least one anomaly flag you can explain
3. The assembly review manifest showing reuse against mint, and the credit cost you approved
4. The generated application's health endpoint running on your laptop

Submit via the certification portal for review.