decide-like-module

Decide like module

Purpose

Decisions are the most valuable layer of a business ontology, and the easiest to waste. A module accumulates dozens of rulings over its life — "we never run a campaign without a confirmed opt-in," "refunds over 30 days go to the area lead," "we don't onboard clients below the minimum deal size" — and most of that knowledge sits inert in decision cards that get written once and read never. The point of capturing decisions was never archival; it was so the module could decide consistently next time. This skill is what turns the stored layer into a working one.

The reasoning behind it matters more than the mechanics. When a new case lands, there are three possibilities, and they call for genuinely different behaviour. Either the module has already effectively decided this — there is a decision card or a rule that covers it, and the right move is to apply that ruling with a citation, so the new case is handled the way every prior case was. Or the case is similar but not identical to a prior ruling — and then the honest move is to recommend by analogy while naming the gap, so a human can see the reasoning is a stretch rather than a match. Or the rules genuinely do not cover it, or two of them point opposite ways, or it is a real expert judgement that only the area owner can make — and then inventing an answer is the worst thing the apprentice can do, because a confident fabrication is indistinguishable from a real ruling once it is written down. The skill exists to make the first case fast, the second case visible, and the third case escalate instead of hallucinate.

This is the apprentice stance. An apprentice does not become the decision-maker; it recommends from accepted precedent. The agent proposes, an authorized human decides, and the deterministic controller applies. Marking a new ruling accepted on agent authority remains forbidden.

When to use

Reach for this skill when:

• Someone asks how the module would handle a specific new or borderline case — a pricing exception, a refund past the window, an unusual onboarding, a "can we skip step X this once?" — and wants the module's own answer, not a generic one.
• You are mid-task in a working repo and hit a choice the module has a stance on ("does this client clear our minimum?", "do we need a second approver here?") and want to answer "as the module would" rather than improvise.
• A human asks "what's our policy on …" for a situation that is not literally written down but is close to things that are.
• You need to check whether a proposed action is consistent with the module's prior decisions before it goes ahead.