Decision Science Corp runs on Sanctum Tasks: what our own client adoption looks like

SanctumOS published the platform story - Tasks as the first production app in the Sanctum productivity suite, the template CRM and siblings inherit. This post is the other half of that story.

Decision Science Corp is the client.

We are not a neutral vendor narrating a reference install. We are the shop that builds Sanctum and the organization that runs daily operations on tasks.decisionsciencecorp.com: boards, directory projects, document library, agent assignments, Ask Q on admin, Otto proof-of-work in comments. That is how we coordinate Sanctum work, client engagements, Empire experiments, and internal runbooks.

If Tasks were a demo tenant, the productivity suite would still be a slide deck. It is not. We polished Tasks because we needed it to survive our habits.

Sanctum Tasks at tasks.decisionsciencecorp.com — the board Decision Science Corp runs daily operations on.

Two hats, one company

DSC wears two hats that are easy to conflate:

Hat	What we do
Platform builder	SanctumOS repos - SMCP, Broca, sanctum-tasks, CRM reference, installer docs
Operating client	Run the business on Tasks - assign work, file docs, comment with proof, ship

Most vendors separate those roles: a product team ships v1, customer success finds a friendly early adopter, marketing writes the case study six months later. We collapsed the loop. The early adopter is the builder. The case study is this post.

That is not virtue signaling. It is a constraint. When Ask Q stalls after fifteen minutes of polling, we feel it because Mark had the panel pinned beside a task thread. When the upload API returns 500 on blog images, we feel it because Otto was trying to file research packets. When CRM looked a generation older than Tasks, we felt it because we bounced between products in the same afternoon.

Client adoption here means production load on our own hostname, not a sandbox we reset on Fridays.

What "extensive use" actually means

Here is what runs on Tasks today - not aspirational roadmap, current practice:

Directory projects as engagement lanes. Centa Social, Invoicing, Document library (otto-portable), blogging research packets, Empire program tracking - each gets a project_id, todo lists, and tasks with real assignees (ottovernal, ada, humans). Orphan todos without a project are treated as a bug, not a feature.

Document library as institutional memory. Bootstrap manuals, API references, editorial calendars, migration runbooks - markdown bodies in Tasks, not scattered gists. When Otto needs the portable bundle architecture, the answer is Doc #223, not a Slack scrollback.

The board as journal, not chat. Chat is ephemeral. Tasks comments are dated, searchable, tied to assignees and status transitions. When Otto ships a slice, the proof lands on the task: commit SHA, verification command, link to admin doc. Discussion-shaped cards stay open until a human closes them - we learned not to treat a long Otto reply as "done."

Agents on the same API as humans. Otto and Ada call /api/ with keys. Q Vernal in Ask Q gets a chatter tool profile - enough verbs to help an operator, not the full admin catalog. SMCP governor attach/detach exists because we refused to give a conversational agent thirty-five tools and pretend that was safe.

Ask Q as daily operator UI. Not a launch demo - all-day hardening exists because DSC operators actually leave the bubble pinned. Poll math, 429 backoff, Broca inbox decoupling - client symptoms, builder fixes.

Heartbeat and open-claw queues. Tasks is where "agent checks board, picks up assigned work, logs proof, marks done" lives. Otto self-assigns, executes, comments - the board is the ledger for agent work, not a side channel.

That is extensive use: multiple namespaces, hundreds of tasks and documents, agents and humans on one ACL model, embedded chat beside real admin workflows.

What the client role forced us to polish

Building the stack and running on it produces a different priority queue than building alone.

Design language. Tasks shipped skins, semantic chips, and a board card contract first. CRM caught up to the same shop because we refused to live with two visual generations in one company. Kitchen POS operator and partner UIs picked up the Sanctum shell for the same reason - operator fatigue is a client complaint.

API-first as non-negotiable. Otto does not scrape Tasks admin HTML. If an action lacks an API endpoint, that is a product gap we file - not a prompt to automate the browser. The *`tasks__`** SMCP plugin and Python SDK exist because the client (us) needed parity.

Upload and attachment durability. Inline images in task bodies and documents go through upload-attachment -> get-asset - not hotlinked GitHub raw URLs that break when repos move. Blog publishing on DSC and SanctumOS converged on the same lesson: bytes need a stable home when agents file evidence.

Rate limits and error codes. Tasks API limits are documented and stable because automation hits them daily. A 429 is a contract, not a surprise - see the Tasks API hardening posts in our archive.

The pattern we keep landing on: client pain -> repo fix -> prod deploy -> documented on the board. Tasks is where that loop is most visible.

How this differs from "we dogfood our product"

Dogfooding is often a checkbox - engineers click around staging once a sprint. DSC client adoption is closer to running the company on the tool:

Client-visible work is tracked in Tasks when engagements require it (Centa discussions, program ops).
Sanctum infra handoffs to Ada go through Broca and often a Tasks row with scope and proof requirements.
Editorial and research pipelines file to the document library; Doc #367 is the blogging backlog Otto actually reads.

We are not pretending to be an external customer with anonymized metrics. We are naming the relationship honestly: Sanctum builds the productivity suite; DSC is the first organization to run on it at scale. Other clients and partners will come; Tasks already has the scars from us.

For other teams evaluating Sanctum Tasks

If you are reading the SanctumOS module doc and wondering whether this is production-ready or conference-ware:

Prod hostname - tasks.decisionsciencecorp.com is our live board, not a marketing mirror.
Open source - sanctumos/sanctum-tasks (AGPL-3.0 code, CC BY-SA docs). Fork, deploy on multihost, wire SMCP.
Companion posts - design language, Ask Q hardening, CRM parity, Porter bridge - all written from the same client/builder loop.
Platform context - SanctumOS - first production app in the productivity suite for stack placement and build order.

You do not need to be Decision Science Corp to use Tasks. You do need to treat /api/ as the contract and plan for agents as first-class users - because that is what our client adoption proved was load-bearing.