"This is what lets 아빠 and the Pippa sidekick co-design a new pipeline in conversation without a code deploy."
A deliberate departure
The heavy analysis in this product runs through a delegation queue: a brief is queued, a session takes it, does the work, and lands a reviewed report. A sibling application uses the same queue kernel, and there the available pipelines live in a code registry — a module listing each pipeline's stages, template and review contract.
Touchstone deliberately does not. Its pipeline definitions live as rows in the database, with full create, update, archive and restore through the engine API. The architecture doc marks it as a departure and gives the reason, which is not about flexibility in the abstract.
It is about who can design a pipeline and when. A code registry means a new kind of analysis requires editing a file, reviewing it, and deploying. Rows mean it can be designed in the conversation where the need surfaced, by the two people having that conversation, and exist immediately.
The invariant that keeps it safe
Making configuration writable at runtime is the kind of decision that goes badly when it is made casually. The safety here is a second invariant sitting right beside the first: the sidekick reads and drafts, the engine gates.
The assistant surface can read all context and propose a pipeline draft. It cannot install one. Every create and update lands through the same engine API a human uses — no privileged side channel.
The architecture doc calls that API audited, and the word is worth checking against the routes, because it is the load-bearing half of the safety argument. What the API gives you today is shared and validated: one path, same validation, no back door. What it does not give you is a trail — create, edit, archive and delete mutate the current row and emit no event, retain no prior revision, and record no actor. A version counter and an updated-at stamp tell you that something changed, not what or who. So the asymmetry that matters is real and enforced, and the audit half is an aspiration the doc states in the present tense. Normal for a young system; the mistake would be reading the doc and believing the trail exists.
That phrase is the whole safety argument in four words. The risk of a conversational configuration interface is not that the assistant proposes something bad; it is that the assistant gets a faster or quieter path than the human, so its changes are less visible. Routing both through one door means a proposal is exactly as reviewable as a human's, and the door does not distinguish between them because it does not need to. Whatever trail that door eventually keeps, it will keep the same one for both.
The compatibility constraint
One operational detail worth noting, because it shows how a family of small applications avoids duplicating work. This module was not written twice. It reached its second use across the family, and the two applications' versions turned out to be byte-identical once the app name was substituted — which is precisely the evidence that promotes something into the shared kit. So it was promoted, and what lives here now is a thin binding that re-exports the exact names the engine, CLI and tests already imported.
That threshold is worth stealing. One use is a solution; two identical uses is a primitive, and the byte-identical test is a much better promotion criterion than a design opinion, because it is checkable. Two independent implementations of the same idea normally diverge in small ways — a field name, a default, an ordering — and each divergence is a merge conflict deferred rather than avoided. When they have not diverged at all, extraction is a move rather than a reconciliation.