@opencxh/domain 1.274.0 → 1.275.0

package/dist/entities/ai-account/capabilities.d.ts

@@ -38,6 +38,10 @@ export declare const AI_CAPABILITIES: readonly [{
     readonly id: "embedding";
     readonly defaultFlag: "isDefaultEmbedding";
     readonly label: "Embeddings";
+}, {
+    readonly id: "decision";
+    readonly defaultFlag: "isDefaultDecision";
+    readonly label: "Beslissingen";
 }];
 /** What an account can be the default for, and what a vendor can claim. One vocabulary. */
 export type AiCapability = (typeof AI_CAPABILITIES)[number]["id"];

package/dist/entities/ai-account/index.d.ts

@@ -1,3 +1,6 @@
 export * from './capabilities';
+export * from './modality';
+export * from './routing';
+export * from './system-one';
 export * from './types';
 export * from './vendors';

package/dist/entities/ai-account/modality.d.ts

@@ -0,0 +1,26 @@
+/**
+ * What one **model** can take in and give back.
+ *
+ * The question used to be asked per *vendor* (`aiVendorAcceptsAttachment`), and that is wrong in
+ * both directions: within one vendor models differ — a small fast model and its flagship do not
+ * read the same things — and it covered input only, so `tts` stayed an account flag with a form
+ * and no adapter behind it.
+ *
+ * The vocabulary is the source's, not ours (`architecture.input_modalities` on OpenRouter), and
+ * deliberately so: it is synced hourly and a translation table here would be a second place to
+ * maintain the same fact. That is why these are plain strings.
+ */
+export interface ModelModality {
+    in: string[];
+    out: string[];
+}
+/**
+ * Does this model accept this kind — or is it simply not in the catalog?
+ *
+ * **Three states, on purpose.** `undefined` means "the catalog does not know this model", which a
+ * caller must be able to tell from a "no": the answer then falls back to what the vendor
+ * declares, rather than silently refusing every attachment on a self-hosted or brand-new model.
+ */
+export declare function modelAcceptsAttachment(modality: ModelModality | undefined, kind: string): boolean | undefined;
+/** Can this model speak? The honest question behind the `tts` flag. */
+export declare function modelProduces(modality: ModelModality | undefined, out: string): boolean;

package/dist/entities/ai-account/modality.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/entities/ai-account/routing.d.ts

@@ -0,0 +1,71 @@
+/**
+ * Which model answers this turn — decided per request instead of once per profile.
+ *
+ * Today nobody chooses: the model stands on the profile, or it is the account's default. Every
+ * question gets the same brain, whether it is *"mark this conversation resolved"* or *"write the
+ * quote letter"*. That is slow on the cheap questions and expensive on all of them.
+ *
+ * The routing rules are **rules**, not a model: the shape of a request is known without asking
+ * anyone. A hop to a classifier here would cost ~100 ms and a call to decide something that is
+ * free to decide.
+ */
+export declare const MODEL_TIERS: readonly ["fast", "standard", "deep"];
+export type ModelTier = (typeof MODEL_TIERS)[number];
+/** Which account and model answer at one level. Both, because a tier can live on another vendor. */
+export interface TierBinding {
+    accountId: string;
+    model: string;
+}
+export type ModelTiers = Partial<Record<ModelTier, TierBinding>>;
+/**
+ * What this turn looks like, in the things that are knowable **before** the model is asked.
+ *
+ * Deliberately no context size, though the plan names it. The size is only known after the turn
+ * is assembled, and the assembly needs the provider, which needs the account, which is what this
+ * decides. The rule it would serve (a small classify goes to `fast`) is carried by
+ * {@link RoutingRequest.expectsSchema}, and that is the case it was written for.
+ */
+export interface RoutingRequest {
+    /** `ask` reads, `draft` prepares, `agent` may act. Absent counts as `agent`. */
+    mode?: string;
+    /** How many tools the profile puts on the table. Zero is the cheap case. */
+    toolCount?: number;
+    hasAttachments?: boolean;
+    /** A structured answer against a schema: classify, extract, judge. */
+    expectsSchema?: boolean;
+    /** This turn repairs a failed one. Measured, not guessed — see the control-repair trace. */
+    repair?: boolean;
+    /** The ceiling the role allows. A cap, never a per-turn choice. */
+    maxTier?: ModelTier;
+    /** `soft` = a budget passed its warning threshold. `hard` never reaches here; it refuses. */
+    budgetPressure?: "none" | "soft";
+}
+export interface RoutingDecision {
+    tier: ModelTier;
+    /** Why, in the order the rules fired. Lands in the run so a bill can be read back. */
+    reasons: string[];
+}
+/**
+ * The tier for one request.
+ *
+ * Order matters and is the whole design: pick a base from the shape, escalate a repair, then
+ * **degrade under budget pressure rather than refuse**, and finally clamp to whatever ceiling the
+ * role set. Degrading last-but-one is deliberate — a cheaper answer is nearly always better than
+ * no answer, and today a full budget is a closed door.
+ */
+export declare function resolveTier(request: RoutingRequest): RoutingDecision;
+export interface Route extends RoutingDecision {
+    accountId: string;
+    model: string;
+    /** False when no tier was bound and the profile's own choice stands. */
+    routed: boolean;
+}
+/**
+ * The tier, resolved to an account and a model.
+ *
+ * **An unconfigured organisation must change nothing.** Tiers are opt-in, so an empty map means
+ * the profile's own account and model answer exactly as they did — which is also why the walk
+ * downward exists: a half-filled ladder (`fast` and `deep`, nothing between) should still route
+ * rather than fall back to the profile and quietly ignore what was configured.
+ */
+export declare function resolveRoute(tiers: ModelTiers | undefined, request: RoutingRequest, fallback: TierBinding): Route;

package/dist/entities/ai-account/routing.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/entities/ai-account/system-one.d.ts

@@ -0,0 +1,109 @@
+/**
+ * The System One contract: ask a model a **question about a state**, get a number back.
+ *
+ * A different shape of model from every other one in this platform. A chat model is handed a
+ * prompt and writes text; this one is handed a state plus a set of typed questions and answers
+ * each of them as a probability distribution. It generates nothing — the docs say so outright —
+ * which is exactly why it is worth having: *"does this answer the question?"* is a yes/no with a
+ * degree, and a chat model asked that writes a paragraph about it.
+ *
+ * **Questions come as a set, and that is the contract rather than an optimisation.** Measured by
+ * the vendor: thirteen questions in one call against a 54k-character document were 12.2× cheaper
+ * and 10× faster than thirteen calls, and each question is scored on its own — batching adds no
+ * cross-talk. Anything that asks one question at a time here is paying twelve times over.
+ */
+/** What a `true` and a `false` mean for this question. Optional; the instructions usually say it. */
+export interface NoulCriteria {
+    true?: string;
+    false?: string;
+}
+export interface NoulQuestion {
+    type: "noul";
+    instructions: string;
+    criteria?: NoulCriteria;
+}
+/** Options as `{ name: description }`. A `null` description means "the name says it". */
+export interface ChoiceQuestion {
+    type: "choice";
+    instructions: string;
+    criteria: Record<string, string | null>;
+}
+/** An ordered rubric, lowest first. */
+export interface ScoreQuestion {
+    type: "score";
+    instructions: string;
+    criteria: string[];
+}
+export type SystemOneQuestion = NoulQuestion | ChoiceQuestion | ScoreQuestion;
+/**
+ * P(yes), 0..1 — the answer and the certainty in one number.
+ *
+ * **No separate `confidence`, and that is deliberate on the vendor's side**: a yes/no has two
+ * outcomes, so one number describes the whole distribution. 0.5 is not "unsure about yes", it is
+ * "yes and no weighed the same".
+ */
+export interface NoulAnswer {
+    type: "noul";
+    noul: number;
+}
+export interface ChoiceAnswer {
+    type: "choice";
+    choice: string;
+    confidence: number;
+    probabilities: Record<string, number>;
+}
+export interface ScoreAnswer {
+    type: "score";
+    score: number;
+    confidence: number;
+    legend?: Record<string, string>;
+    probabilities?: Record<string, number>;
+}
+export type SystemOneAnswer = NoulAnswer | ChoiceAnswer | ScoreAnswer;
+export interface SystemOneRequest {
+    /** The thing being judged. A string, or a labelled object — the labels are read. */
+    state: unknown;
+    model?: string;
+    questions: Record<string, SystemOneQuestion>;
+}
+export interface SystemOneResponse {
+    model: string;
+    answers: Record<string, SystemOneAnswer>;
+    usage?: {
+        input_tokens?: number;
+        output_tokens?: number;
+    };
+}
+/** Vendor limits, so a request is refused here rather than as a 422 nobody reads. */
+export declare const MAX_CHOICE_OPTIONS = 255;
+export declare const MIN_SCORE_LEVELS = 2;
+export declare const MAX_SCORE_LEVELS = 10;
+/**
+ * What is wrong with this question set, or `null`.
+ *
+ * Checked before the call because the alternative is a 422 with a vendor's wording in a log, and
+ * because these are the mistakes a caller makes while writing a question rather than at runtime.
+ */
+export declare function validateQuestions(questions: Record<string, SystemOneQuestion>): string | null;
+export type DecisionBand = "act" | "check" | "refuse";
+/**
+ * What to *do* with a number, in three bands.
+ *
+ * The vendor is explicit that the thresholds are domain-specific and that you should start
+ * conservatively — so they are parameters, not constants, and the default is deliberately timid.
+ * The three bands are the vendor's own architecture advice: act, act-but-confirm, do not act.
+ *
+ * **`check` is the honest middle and must not be collapsed.** Two bands force every uncertain
+ * answer into either a silent action or a dead end; the middle is where a human gets asked, which
+ * is the entire reason a calibrated number is worth more than a label.
+ */
+export declare function decisionBand(value: number, act?: number, check?: number): DecisionBand;
+/**
+ * Questions this model should not be asked.
+ *
+ * Straight from the vendor's own jaggedness page, and worth having in code rather than in a
+ * doc: counting, arithmetic, raw numeric values and **dates** are named failure modes — it
+ * "reads dates as text, not as ordered quantities". Every one of those has a deterministic
+ * answer in this codebase already, so asking a model is both worse and more expensive.
+ */
+export declare const SYSTEM_ONE_NON_GOALS: readonly ["counting or arithmetic", "comparing dates or durations", "judging whether two numbers are close", "generating text"];

package/dist/entities/ai-account/system-one.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/entities/ai-account/types.d.ts

@@ -1,4 +1,5 @@
-export interface AiAccount {
+import { AiDefaultFlags } from './capabilities';
+interface AiAccountFields {
     id: string;
     organizationId: string;
     vendor: string;
@@ -9,8 +10,14 @@ export interface AiAccount {
      * is ignored.
      */
     baseUrl?: string;
-    isDefaultLlm?: boolean;
-    isDefaultStt?: boolean;
-    isDefaultTts?: boolean;
-    isDefaultEmbedding?: boolean;
 }
+/**
+ * The default flags, **derived** from the capability catalog rather than listed again.
+ *
+ * They were written out by hand here, which is the drift the catalog exists to stop: adding
+ * `decision` gave every other place a fifth checkbox and this interface a fourth, so the form
+ * offered a flag the type did not have. One list, everything else follows.
+ */
+export interface AiAccount extends AiAccountFields, Partial<AiDefaultFlags> {
+}
+export {};

package/dist/entities/ai-message/types.d.ts

@@ -97,6 +97,13 @@ export interface AIMessage {
     toolsTotal?: number;
     /** Which mode this turn ran as. Absent = `"agent"`: every row written before modes existed. */
     mode?: AssistantMode;
+    /**
+     * Why this model answered — one line per routing rule that fired.
+     *
+     * Absent when nothing was routed, which is every organisation that bound no tiers. A reason for
+     * a choice nobody made would read as a decision.
+     */
+    routing?: string[];
 }
 export type AIMessageFeedback = "up" | "down";
 /**

package/dist/entities/ai-settings/types.d.ts

@@ -1,3 +1,4 @@
+import { ModelTiers } from '../ai-account/routing';
 /**
  * What an organisation configures for the AI app as a whole — not per profile, not per user.
  *
@@ -5,6 +6,14 @@
  * setting nobody can find.
  */
 export interface AiOrgSettings {
+    /**
+     * Which account and model answer at `fast`, `standard` and `deep`.
+     *
+     * **Opt-in and empty by default.** An organisation that configures nothing keeps exactly what
+     * it has: the profile's own model answers every turn. Only once a tier is bound does the router
+     * (`resolveRoute`) get anything to choose between.
+     */
+    tiers?: ModelTiers;
     /**
      * May the AI app listen in on conversations (speech to text)?
      *

package/dist/entities/eval/index.d.ts

@@ -0,0 +1,2 @@
+export * from './runner';
+export * from './types';

package/dist/entities/eval/runner.d.ts

@@ -0,0 +1,14 @@
+import { EvalCase, EvalCaseResult, EvalRun } from './types';
+/**
+ * Run a suite. The judge is injected, which is the whole reason this is one function.
+ *
+ * A deterministic suite (rule correctness, a classification against a known answer) judges by
+ * comparison and costs nothing; a judged suite asks a model. Both are the same loop, and keeping
+ * that loop in one place is what makes "put this in CI" a decision about the judge rather than a
+ * second implementation.
+ *
+ * **Sequential, not parallel.** A judged suite is a batch of model calls, and firing forty at
+ * once is how a rate limit turns a measurement into a red build. A deterministic judge is fast
+ * enough that the difference does not register.
+ */
+export declare function runEvalSuite<I, E>(suite: string, target: string, cases: readonly EvalCase<I, E>[], judge: (testCase: EvalCase<I, E>) => Promise<EvalCaseResult> | EvalCaseResult, now?: number): Promise<EvalRun>;

package/dist/entities/eval/runner.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/entities/eval/types.d.ts

@@ -0,0 +1,46 @@
+/**
+ * Measuring whether this platform is any good at the things it decides.
+ *
+ * Today that exists once, as a test file inside the playbook folder: a handful of cases, opt-in,
+ * never in CI. That is not small-but-good, it is the wrong shape — it measures one kind of thing
+ * (a playbook prompt) while seven things need exactly the same machinery: prompt quality, the
+ * accuracy of a classification, **rule correctness**, retrieval, tool selection, whether an agent
+ * turn reached its control move, and live answer quality.
+ *
+ * Two design rules live in the shape itself. A case carries either an `expected` value **or** a
+ * `rubric`, because those are the two ways anything here can be judged: exactly, or by opinion —
+ * and an opinion needs a judge, which costs money and has to be calibrated. And a case is
+ * something you can *harvest*: every correction in the feedback loop is by definition a labelled
+ * case, while a golden set written by hand is out of date within a quarter.
+ */
+export interface EvalCase<Input = unknown, Expected = unknown> {
+    id: string;
+    /** What kind of thing is judged: `rule`, `classify`, `retrieval`, `tool-selection`, … */
+    subject: string;
+    input: Input;
+    /** The exact answer, when there is one. Mutually exclusive with {@link EvalCase.rubric}. */
+    expected?: Expected;
+    /** What "good" means, for a case only a judge can settle. */
+    rubric?: string;
+    tags?: string[];
+}
+export interface EvalCaseResult {
+    caseId: string;
+    ok: boolean;
+    /** What actually happened, in the case's own terms. Present on a failure; optional otherwise. */
+    got?: unknown;
+    /** Why it failed, in a sentence a person can act on. */
+    note?: string;
+}
+export interface EvalRun {
+    suite: string;
+    /** What was measured: a model id, a rule set version, a prompt. */
+    target: string;
+    at: number;
+    /** Passed over total, 0..1. `1` on an empty suite — nothing failed. */
+    score: number;
+    perCase: EvalCaseResult[];
+}
+export declare function summariseEval(suite: string, target: string, perCase: readonly EvalCaseResult[], at?: number): EvalRun;
+/** The failures, as lines. What a CI log should print and nothing more. */
+export declare function failureLines(run: EvalRun): string[];

package/dist/entities/inbox/types.d.ts

@@ -11,10 +11,10 @@ export interface Inbox {
     /**
      * Hours a first reply may take in this inbox before a conversation counts as at risk.
      *
-     * Absent = the ladder per priority ({@link SLA_HOURS_BY_PRIORITY}), which is what every
-     * organisation silently ran on: the onboarding step promised a norm per inbox, ticked itself
-     * off on `ticketEnabled`, and nothing anywhere stored an agreed number. So the Focus badge and
-     * Assist' SLA nudge were a hardcoded opinion.
+     * **Absent = no service target at all**, not a default. A ladder per priority used to stand in
+     * (1/4/8/24) and that was a hardcoded opinion: every inbox, and every conversation outside one,
+     * silently carried a promise nobody made. Deliberately not being in an SLA — personal mail —
+     * is the common case, so it is the one that needs no configuration.
      *
      * One number and not four (one per priority): an inbox usually *is* the agreement ("support:
      * within 4 hours"), and four fields per inbox is four things to keep consistent while the

package/dist/entities/interaction/attention.d.ts

@@ -1,4 +1,4 @@
-import { AttentionCtx, ParkMark, Priority, Scored } from '../../platform/attention';
+import { AttentionCtx, ParkMark, Scored } from '../../platform/attention';
 import { Interaction } from './types';
 /** The only statuses that can ask for attention; `closed` and `snoozed` never compete. */
 export declare const ATTENTION_STATUSES: readonly ["open"];
@@ -15,11 +15,6 @@ export declare const ATTENTION_STATUSES: readonly ["open"];
  * larger than any positive contribution, so bulk always ranks below every real conversation.
  */
 export declare const BULK_PENALTY = 1000;
-/**
- * Hours a first response is "allowed" per priority before an open interaction counts as
- * SLA-at-risk. Also consumed by the Mijn dag KPI and the wait heuristic.
- */
-export declare const SLA_HOURS_BY_PRIORITY: Record<Priority, number>;
 /**
  * How long you wait for a reply before the conversation asks for attention again. Without this
  * bound a thread the customer never replied to would stay out of sight forever.
@@ -48,16 +43,17 @@ export declare function isReminderActive(reminder: ParkMark | undefined, i: Inte
 /** Whole hours an open interaction has been waiting (never negative). */
 export declare function waitHoursOf(i: Interaction, now: number): number;
 /**
- * The first-reply budget for this conversation, in hours.
+ * The first-reply budget for this conversation in hours, or `undefined` when nobody agreed one.
  *
- * The inbox's own norm wins when it has one; otherwise the ladder per priority. One helper
- * rather than the lookup at each call site, because three readers ask this question (the Focus
- * badge, "Mijn dag", and Assist' nudge tag) and a fourth answer would be a fourth opinion.
+ * **There is deliberately no fallback.** A ladder per priority used to fill this in (1/4/8/24),
+ * which invented an agreement nobody made: a personal mailbox got an eight-hour promise for the
+ * sole reason that its priority was unset. "No service target" is a valid state — most mail is
+ * in it — and it has to look different from a target someone actually configured.
  *
  * A non-positive stored value is treated as absent: "0 hours" is not an agreement, it is an
  * empty field that made it through a form.
  */
-export declare function slaHoursFor(i: Interaction, slaByInbox?: Record<string, number>): number;
+export declare function slaHoursFor(i: Interaction, slaByInbox?: Record<string, number>): number | undefined;
 /**
  * Index inboxes the way {@link slaHoursFor} wants them: only the ones that named a norm.
  *
@@ -71,8 +67,11 @@ export declare function slaHoursByInbox(inboxes: readonly {
 /**
  * True when an open interaction has waited past its first-reply budget.
  *
- * `slaByInbox` maps inbox id -> agreed hours; a caller that has no inboxes at hand may leave it
- * out and gets the priority ladder, which is exactly the old behaviour.
+ * No budget, no risk. A conversation in an inbox that named no norm cannot be late, because
+ * there is nothing to be late for — so the answer is `false`, not "unknown". The one reader is a
+ * badge, and a badge that fires on an agreement that does not exist is the bug this removed.
+ *
+ * `slaByInbox` maps inbox id -> agreed hours; leave it out and nothing is ever at risk.
  */
 export declare function isSlaAtRisk(i: Interaction, now: number, slaByInbox?: Record<string, number>): boolean;
 /**

package/dist/entities/kb/index.d.ts

@@ -1,4 +1,5 @@
 export * from './help-center';
+export * from './keys';
 export * from './locales';
 export * from './tree';
 export * from './types';

package/dist/entities/kb/keys.d.ts

@@ -0,0 +1,2 @@
+/** The scope kind of one article: `article:<id>`. One definition for the claim and the owner. */
+export declare const ARTICLE_SCOPE_KIND = "article";

package/dist/entities/rule/bind.d.ts

@@ -0,0 +1,8 @@
+/**
+ * Fill `{{path}}` references in action params from what the rule saw (`{ event, subject }`).
+ *
+ * A param that is *only* a reference keeps the referenced value's type (`"{{subject.id}}"` → the
+ * id, a number stays a number); a reference inside longer text is stringified. An unresolvable
+ * path becomes `""` — the same "empty is not an instruction" the tools already read.
+ */
+export declare function bindParams(params: Record<string, unknown>, context: Record<string, unknown>): Record<string, unknown>;

package/dist/entities/rule/bind.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/entities/rule/cron.d.ts

@@ -0,0 +1,40 @@
+/**
+ * Does this cron expression name this minute?
+ *
+ * Five fields, standard order: `minute hour day-of-month month day-of-week`. Each field is `*`,
+ * a number, a range (`a-b`), a step (`*` slash `n`), or a comma-separated list of those.
+ *
+ * **Hand-written and not a library.** It is thirty lines, it has to run inside QuickJS, and the
+ * alternative is a dependency in `packages/domain` — which carries none, on purpose. What it
+ * deliberately does **not** support is the part of cron nobody writes by hand: `L`, `W`, `#`,
+ * named months and weekdays, and seconds. An expression using one of those is refused rather
+ * than quietly matching nothing, which is the failure mode a scheduled rule cannot afford — a
+ * rule that never fires looks exactly like a rule whose condition is never true.
+ */
+export interface ParsedCron {
+    minute: Set<number>;
+    hour: Set<number>;
+    dayOfMonth: Set<number>;
+    month: Set<number>;
+    dayOfWeek: Set<number>;
+    /** True when either day field was left as `*` — see {@link cronMatches}. */
+    anyDayOfMonth: boolean;
+    anyDayOfWeek: boolean;
+}
+/** `null` when the expression is not one this matcher can honour. */
+export declare function parseCron(expression: string): ParsedCron | null;
+/** Is this expression one this matcher can honour at all? */
+export declare function isSupportedCron(expression: string): boolean;
+/**
+ * Does this expression name the minute `date` falls in?
+ *
+ * The day rule is cron's one genuine oddity and it is kept: when **both** day fields are
+ * restricted they are OR-ed, not AND-ed — `0 9 1 * 1` means "the first of the month, and every
+ * Monday", not "a Monday that is the first". Every cron implementation does this, and quietly
+ * doing the intuitive thing instead would make a rule fire on a handful of days a year.
+ *
+ * Evaluated in **UTC**, because that is what the tick that calls it runs in. A rule author who
+ * means nine in the morning in Amsterdam writes the UTC hour; naming a timezone per rule is a
+ * field this type does not have yet, and guessing the organisation's is worse than the omission.
+ */
+export declare function cronMatches(expression: string, date: Date): boolean;

package/dist/entities/rule/cron.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/entities/rule/eval.d.ts

@@ -0,0 +1,31 @@
+import { EvalCase, EvalCaseResult } from '../eval/types';
+import { Rule, RuleEvent } from './types';
+/**
+ * The first eval suite, and the one that is free: **does this rule set do what its author said?**
+ *
+ * Deterministic, no model, no network — which is what makes it the suite that belongs in CI. The
+ * whole question is whether `matchRules` plus a condition produces the actions somebody expected,
+ * and every part of that is already pure.
+ *
+ * This is the check that would have caught the shipped starter template pointing at
+ * `subject.lastActivityPreview.text`: a field no conversation has, so the rule compared
+ * `undefined`, never fired, and said nothing about why. It was found by hand, once. A case says
+ * "this event, this rule, these actions" and it stays found.
+ */
+export interface RuleCaseInput {
+    event: RuleEvent;
+    rules: Rule[];
+}
+export interface RuleCaseExpected {
+    /** The actions that should fire, in order. An empty list means "this must not fire". */
+    actions: string[];
+}
+export type RuleEvalCase = EvalCase<RuleCaseInput, RuleCaseExpected>;
+/**
+ * Judge one rule case.
+ *
+ * The evaluator is injected and the caller is expected to pass **the production one**. A suite
+ * with its own condition semantics measures its own semantics; the point is to measure what will
+ * actually run.
+ */
+export declare function judgeRuleCase(testCase: RuleEvalCase, evaluate: (condition: unknown, context: Record<string, unknown>) => boolean): EvalCaseResult;

package/dist/entities/rule/index.d.ts

@@ -1,4 +1,8 @@
+export * from './bind';
 export * from './condition';
+export * from './cron';
+export * from './eval';
 export * from './match';
+export * from './outcome';
 export * from './trigger-source';
 export * from './types';

package/dist/entities/rule/match.d.ts

@@ -1,4 +1,12 @@
 import { Rule, RuleEvent } from './types';
+/**
+ * The event name a clock tick carries.
+ *
+ * A reserved name and not a kind of its own, so the tick travels through the same matcher, the
+ * same guards and the same idempotency key as everything else. `@` cannot occur in an
+ * `<app>:<resource>:<verb>` name, so no app can ever deliver it by accident.
+ */
+export declare const SCHEDULE_EVENT = "@schedule";
 /**
  * How deep a chain of rules may go before it is refused.
  *

package/dist/entities/rule/outcome.d.ts

@@ -0,0 +1,42 @@
+/**
+ * Is what a rule wrote still standing?
+ *
+ * The feedback loop's first real signal, and it needs no new write path: every run already
+ * carries `priors` — the previous value of each field it wrote, plus the params it wrote them
+ * with — because undo needs exactly that. Asking the same question an hour later turns it into a
+ * measurement.
+ *
+ * **Why this matters more than an approval rate.** The trust ladder promotes on *observed
+ * unchanged approval*, and approving is a ritual — people click yes. A correction is a real
+ * objection, and so is an undo. An automatic action that could be reversed in one click and never
+ * is, is a stronger promotion signal than any approval percentage; a burst of corrections is an
+ * immediate demotion signal.
+ */
+export type RunOutcome = "kept" | "corrected" | "undone" | "unknown";
+/** The half of an action's prior this question needs. `before` is undo's business, not this one. */
+export interface OutcomePrior {
+    action: string;
+    params: Record<string, unknown>;
+    /** Which params were content — a field the subject owns — rather than addressing. */
+    fields: string[];
+}
+/**
+ * Which fields no longer hold what the action put there.
+ *
+ * Shared with the undo, deliberately: "changed since" decides both whether an undo may run and
+ * whether this run counts as corrected, and two definitions of that would eventually disagree —
+ * with the undo overwriting somebody's change while the measurement called it kept.
+ *
+ * A field the subject does not report at all (`undefined`) is **not** drift. That is a reader
+ * that did not return the column, not a person who changed it, and counting it would turn every
+ * thin read into a wave of false corrections.
+ */
+export declare function driftedFields(prior: OutcomePrior, current: Record<string, unknown> | undefined): string[];
+/**
+ * The outcome of one run.
+ *
+ * `unknown` when the subject cannot be read — it was deleted, or its kind has no reader. Kept
+ * apart from `kept` on purpose: "nobody objected" and "we could not look" are different facts,
+ * and folding the second into the first is how a trust ladder promotes on silence.
+ */
+export declare function runOutcome(priors: readonly OutcomePrior[], current: Record<string, unknown> | undefined, undoneAt?: number): RunOutcome;

package/dist/entities/rule/outcome.test.d.ts

@@ -0,0 +1 @@
+export {};