Sense 51: The Skill — cross-domain analytical patterns

Sense 51 · Forming · Last touched 2026-08-20

• last_verified: 2026-07-27

Synced from docs/design/sense_51_the_skill.md in the engine repo — that’s the source; this page is a build-time mirror.

Working principle: a Skill is a what that many packs can answer. A pack is a how that answers many Skills.

Why this Sense exists

jinflow ships analytical frameworks packaged as domain packs — nuMetrix for hospital material flow, hrcentral for workforce analytics, interlogic for freight forwarding, and so on. Each pack ships a self-contained diamond: signals, perspectives, theses, verdicts, Subject Matter, dossiers, all grounded in the pack’s Gold entities.

What the packs don’t share is the analytical intent. When a hospital CFO asks “how is our cost efficiency?”, the answer is nuMetrix-flavoured — I/O coefficients, price palette outliers, catalogue stagnation. When an HR director asks the same question, the answer is hrcentral-flavoured — contractor conversion, overtime burn, benefit utilisation. The vocabulary, the entities, the interpretations differ — but the underlying question is the same. The two packs answer the same cross-domain analytical Skill in different substrates.

Today jinflow has no first-class concept for that shared intent. The closest thing is the category field that every signal and thesis carries:

packs/numetrix/signals/signal_stale_catalogue.yaml

registry:
  signal_category: financial_anomaly
  risk_tier: operational_signal

packs/hrcentral/theses/thesis_overtime_burn.yaml

category: financial_anomaly

financial_anomaly is a string. Nothing else. There’s no registry of what “financial anomaly” means. There’s no discovery path from a category name to every signal or thesis that instances it. There’s no way for a customer to say “show me every pack that offers financial anomaly analysis.” The concept is present in the codebase as accidental spelling agreement, not as architecture.

Sense 51 proposes to promote that latent axis to a first-class concept: the Skill.

Vocabulary

Term	Meaning in this Sense
Skill	A named, reusable analytical intent — a family of questions, patterns of investigation, and interpretations that transcend any single domain. Example: Financial Performance Management. Also called Business Skill in prose when disambiguation is needed.
Domain pack	jinflow’s existing unit of packaging: signals + theses + verdicts + Subject Matter grounded in a Gold contract. Example: nuMetrix.
Instantiation	A pack binding a Skill to its Gold entities. One Skill × N packs = N instantiations, each expressed in that pack’s vocabulary.
Category (legacy)	The current signal_category / thesis category string. Proto-form of Skill. This Sense’s Phase 1 is to promote them.

Naming note. The word “capability” was deliberately not chosen: it already belongs to Sense 25’s identity / auth namespace (capability_map, capabilities.ts, pass_definition). Using “Skill” for the business-side concept avoids a large codebase rename and — as a bonus — reads plainer. Slugs, tables, and YAML fields are skill throughout code (skill_registry, skill_id, packs/skills/); prose uses “Business Skill” or “Skill” interchangeably.

The core claim

Skills are horizontal. Packs are vertical. They form a matrix:

                                                            packs →
                     nuMetrix    hrcentral    interlogic    lexflow
                    ┌──────────┬───────────┬───────────────┬─────────┐
 Financial          │   45     │    12     │      8        │    -    │
  Performance       │ signals  │  signals  │   signals     │         │
  Management        │          │           │               │         │
 Skills   ─────────┼──────────┼───────────┼───────────────┼─────────┤
    ↓               │          │           │               │         │
 Process            │   22     │    18     │     14        │    5    │
  Compliance        │ signals  │  signals  │   signals     │ signals │
                    ├──────────┼───────────┼───────────────┼─────────┤
 Data Quality       │   35     │    27     │      9        │   12    │
                    │ signals  │  signals  │   signals     │ signals │
                    └──────────┴───────────┴───────────────┴─────────┘

               each cell = signals + theses + verdicts that
                            instantiate that Skill
                             inside that pack's Gold contract

This axis is neither above nor below any existing tier of the diamond. It runs orthogonal to all of them. That orthogonality is what makes Skill worth a Sense number rather than a field.

What it unlocks

Three things that are hard or awkward today:

1. Reuse across packs. A pack author browsing a Skill’s spec learns the questions to ask before deciding which signals to build. Instead of every pack reinventing “cost variance analysis” from scratch, a Skill’s JinDesk page lists patterns, sensible severity thresholds, common evidence chains — a template that constrains without dictating.

2. Vocabulary for consulting engagements. Customer conversations move from pack-language to Skill-language: “Do you need Cost Efficiency or Process Compliance?” → “Both.” → “We have nuMetrix and hrcentral packs that instantiate both — here’s what you’d see.” The buyer answers in the Skill’s vocabulary; jinflow maps to packs.

3. A cross-pack discovery surface. A landing page at /skills/<slug> lists every signal, thesis, and verdict across every installed tenant that instantiates that Skill. Money-at-risk rolls up. Comparison across packs becomes native rather than manual.

Three levels of reuse mechanic

The Sense can land at three progressively-ambitious levels:

Level 1 — Tag-only

Signals, theses, verdicts, and dossiers declare skill: cost-efficiency in their YAML. A Skill registry (packs/skills/*.yaml in the engine, or a shared repo) lists Skill id + display name + tri-lingual description + typical severity language. JinDesk surfaces rollups by Skill. No compilation, no code generation. Everything else is just discovery.

This is the safest first move — cheap, additive, no risk of over-abstraction. Categories become Skill tags with minor renaming.

Level 2 — Template

Skill YAML defines a shape: expected signal types (trend + distribution + duplicate), suggested severity rules, expected evidence roles, prose skeletons for interpretations. Packs bind by declaring which Gold entity plays each role.

Cost: pack authors gain guidance but lose freedom. If Skill templates grow prescriptive, they can constrain packs into patterns that don’t quite fit. Governance question: who authors templates? A jinflow-central asset, or a first-mover pack’s public offering?

Level 3 — First-class artefact

Skill has its own YAML DSL, its own compile step, its own KLS registry table (skill_registry, skill_instantiation). It appears in JinDesk as a peer of Signal / Thesis / Verdict — not just a discovery filter. It aggregates money-at-risk across all pack instantiations. Cross-pack comparison becomes a Compare-style route: /compare?skill=cost-efficiency&packs=numetrix,hrcentral.

Cost: significant new machinery. Justified only if Levels 1–2 prove the axis matters commercially.

Recommended landing sequence: ship Level 1 (tags + rollup) with the Sense, plan Level 2 as a follow-up if adoption sticks, defer Level 3 until a customer explicitly needs the cross-pack Compare surface.

Open questions (to resolve during elaboration)

1. Who authors a Skill? Three plausible models:

   • Engine-central: shipped in the jinflow engine repo, versioned with the engine. Universal vocabulary. Least flexible.
   • Skill pack: a distinct pack type in the packhub (like jinflow-skill-fpm) that domain packs depend on. Reuses the packhub distribution model. Introduces pack-of-packs dependency graph.
   • First-mover ownership: the pack that introduces a Skill “owns” it, others adopt via reference. Simplest, but ownership is political — who forks when the definition needs to fork?

2. Where does the Skill’s authoritative definition sit for translation and terminology consistency? Two candidates:

   • The engine’s glossary (like Sense 14’s canonical vocabulary), with a display name and description shipped in en/de/fr.
   • The Skill YAML itself, with translations attached to each Skill declaration. The first is easier to enforce cross-pack consistency; the second is easier for a pack author to iterate on. Probably both, with the engine glossary winning on conflict.

3. Does a Skill define its own severity language? A signal currently declares severity_rules in its own YAML. A tenant might want to say “for Financial Performance, high severity means > $100k money at risk; for Data Quality, high means > 5% of rows affected.” That’s cross-signal, Skill-scoped. Answering yes brings us closer to Level 2/3; answering no keeps us at Level 1.

4. Relationship to the AFS’s analytical_defaults: (Sense 43)? Sense 43 cascades defaults through layers (engine → pack → tenant → perspective). Should Skill be a namespace inside that cascade? Or its own axis? Likely the latter, but worth confirming.

5. Does a Skill register with a pack Contract? A Skill might declare “I need an entity that answers money_at_risk and a time-series of event_count.” A pack instantiates by mapping its Gold entities to those roles. This is close to the Level 2 template model and mimics Sense 14.2’s typed-entity contract shape. Worth exploring in the follow-up spec.

Non-goals

• Not a replacement for domain packs. Packs remain the unit of distribution and the seat of Gold entities. Skills live above, as a discovery + governance axis. A pack without any Skill declarations remains a valid pack.
• Not tied to specific vertical markets. Skills are horizontal by construction — “Financial Performance Management” is meaningful in hospitals, HR, freight, and law equally. Anything that only makes sense in one domain is a signal, not a Skill.
• Not a workflow engine. Skills describe what to look for, not what to do about it. The action layer stays with Verdicts and Interventions (Sense 19).

Companion Sense docs

• Sense 14 — The Signal — where category currently lives as a string field. Sense 51 promotes those categories.
• Sense 14.2 — Typed Signals — the typed-entity contract that Level 2 templates would extend.
• Sense 25 — The Pass — the auth-capability namespace whose vocabulary this Sense deliberately avoids re-using (see the Naming note under Vocabulary).
• Sense 43 — The Cascade — where analytical defaults live; possible integration point.

Implementation sketch (Level 1)

Not committed — this is a preview of what a first cut would touch, to help elaboration weigh scope.

New

• packs/skills/*.yaml (or a dedicated repo jinflow-skills) — one YAML per Skill. Fields: skill_id, display_name (en/de/fr), description (en/de/fr), family (rollup grouping), typical_signal_types (advisory only).
• scripts/skillcompile.py — validate + bake skill_registry into every KLS (like signal_registry today).
• explorer/src/routes/skills/+page.svelte — index of Skills across installed tenants.
• explorer/src/routes/skills/[skill_id]/+page.svelte — one Skill’s rollup: signals × packs matrix, aggregated money-at-risk, cross-pack comparison affordance.

Modified

• Every signal / thesis / verdict / dossier YAML gains an optional skill: field. signalcheck.py warns (not errors) when absent. Existing category values map to skill via a compatibility table for one release.

Removed (eventually)

• signal_category string field, once every pack has migrated its categories to Skill tags. Slow deprecation over multiple releases.

Recommendation

Land as Sense 51 — The Skill, at Level 1 (tag-only + JinDesk rollup) in the first cut. Defer Levels 2/3 until a customer signal justifies the machinery.

---

Numerical neighbors: ← Sense 50: The Beacon · Sense 52 — The Cartography →