Skip to content
C.W.K.
Stream
Lesson 03 of 05 · published

When a Row Is Enough

~12 min · right-sizing, configuration, generic-workshop, boundaries

Level 0Cold Vessel
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

When a Row Is Enough

A named row is enough when the task shape differs through policy the existing engine already knows how to enforce. A template can express instructions, required stages can express proof boundaries, review default can express ordinary scrutiny, and a hint can improve launch without changing authority.

Rows are cheap to inspect, version, archive, and compare. They keep operators inside one queue and one record system. That economy matters: every new application adds runtime ownership, deployment, UI maintenance, health checks, documentation, and another place for state to diverge.

Do not mistake rich instructions for product pressure. A long template may still fit a row if it describes one recurring task. The stronger graduation signals are new lifecycle states, durable domain entities, specialized material rules, interactive workflows, or verification semantics the generic engine cannot represent.

Likewise, high stakes alone do not require an app. A strict review default and additional required stages may carry a rare but sensitive task safely. Birth software only when the generic contract would become dishonest or contorted.

Use the Row-Fit Questions

Ask whether every difference can be expressed as template, known stages, review policy, and hints; whether destination remains task-owned; and whether existing records can explain the work. If yes, keep the row.

A row should not call arbitrary code to stay enough. The moment it needs product-specific executable hooks throughout the lifecycle, you are hiding an application inside configuration.

Stay a row while variation remains expressible as bounded input. If one template, stage vocabulary, review policy, and landing receipt can carry the work without hidden branches, configuration is enough. Resisting a new app here keeps fixes and audit rules in the shared kernel.

Code

Use capability questions instead of a prestige score·python
needs = {
    "new_lifecycle_states": False,
    "durable_domain_entities": False,
    "specialized_material_policy": False,
    "custom_interactive_workflow": False,
}
row_is_enough = not any(needs.values())
assert row_is_enough
print("keep the named pipeline row")

External links

Exercise

Evaluate a recurring task with the row-fit questions. Argue for keeping it as a pipeline even if it is important and heavily reviewed.
Hint
Focus on lifecycle and state, not prestige.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.