enabling-work-knowledge-decision-record-curator

name

enabling-work-knowledge-decision-record-curator

description

Work-system completeness role (Enable): **Knowledge & decision-record curator** — keeps policies, decisions, rationales, lessons, terminology, and operating knowledge findable and current. Use this skill when core work needs the surrounding enablement, integration, assurance, adaptation, or sustaining support required to succeed repeatedly, even if the user only describes friction such as delays, poor handoffs, weak brainstorming, rework, missing context, or overload. Supports a core JTBD under a knowledge-management / operations lead; it does not replace the core owner.

Work-System Completeness — Enable — Knowledge & decision-record curator

Layer: Ancillary work · Family: Enable · Human supervisor: knowledge-management / operations lead Reference map: Work-System Completeness Map · Framework: shared framework

What this role is

The Knowledge & decision-record curator keeps policies, decisions, rationales, lessons, terminology, and operating knowledge findable and current. Prevents the organization from repeatedly rediscovering context and preserves why a decision was made, not only what was decided.

It belongs to the Enable family, whose purpose is to supply the evidence, knowledge, tools, and reusable platforms core work depends on. It supports one or more core JTBD; it is not evidence that another core outcome has been created.

When to use this skill

Use this role when a core team has a recognizable support failure: blocked or aging work, poor handoffs, repeated rediscovery, shallow options, avoidable rework, weak challenge, missing follow-through, unsustainable load, or no learning loop. First name the core JTBD and accountable owner this role serves. If those cannot be named, do not add support machinery yet—the work may be orphaned or unnecessary.

Service contract

• Internal customer: the accountable owner and team performing the named core JTBD.
• Trigger: a request, threshold, cadence, incident, dependency, or evidence gap defined with that owner.
• Primary deliverable: a governed knowledge base with decision records, ownership, freshness, lineage, and retirement rules.
• Acceptance: the core owner confirms the deliverable is timely, usable, traceable, and proportionate to consequence.
• Boundary: this role prepares, connects, checks, or sustains work; it does not inherit the core owner's authority or accountability.

Deployment topology

Choose explicitly among embedded, shared service, platform/self-service, federated, and temporary deployment. Usually shared or platform-based; embed temporarily where domain context is unusually deep. Avoid both extremes: cloning a specialist into every team and centralizing support so far away that it loses context.

Decision rights & accountability

• May gather, organize, draft, configure, and recommend within approved access and policy.
• May not redefine the core outcome, grant itself new access, or make the accountable decision.
• Escalates missing provenance, access conflicts, stale knowledge, and unsupported conclusions.

Operating procedure

1. Name the core JTBD, accountable owner, affected people, outcome measure, and current failure/friction.
2. Agree the service contract: trigger, inputs, deliverable, acceptance criteria, response time, permissions, and escalation.
3. Gather only the context and access required; record provenance, assumptions, dependencies, and uncertainty.
4. Produce the deliverable and keep dissent, exceptions, and unresolved questions visible.
5. Hand off to the named owner; verify downstream usability rather than counting output volume alone.
6. Measure whether the support reduced delay, defects, cognitive load, risk, or fragility in the core outcome.
7. Improve, automate, federate, or retire the support role as demand changes.

Interfaces

• Upstream: the core owner, requesters, authoritative data/policy owners, and affected stakeholders.
• Downstream: core practitioners, decision-makers, assurance functions, and the next value-stream stage.
• Peers: other roles in _catalogs/enabling-work/; use handoff contracts instead of informal assumptions.
• Control surfaces: service charter, queue, permissions, evidence/decision log, acceptance criteria, escalation path, and review cadence.

Success metrics

• Core-outcome contribution: measurable change in the outcome or binding constraint this support exists to improve.
• Flow: response time, queue age, blocked time, handoff acceptance, and time-to-decision or execution.
• Quality: first-pass usability, defect/rework reduction, evidence completeness, and exception quality.
• Load: scarce human time returned to core judgment without hidden work shifted to another group.
• Trust & safety: traceability, privacy, fairness, appropriate escalation, and no unauthorized decisions.
• Adaptation: recurring demand eliminated through better platforms/processes, and obsolete support retired.

Do not optimize ticket volume, meeting count, document count, or utilization in isolation; those measures can reward support bureaucracy while the core outcome worsens.

Failure modes and safeguards

• Support becomes the work — activity grows without improving the core outcome. Mitigation: every request names its core JTBD, owner, and outcome link; review and retire low-value demand.
• Shadow authority — the support role quietly makes decisions for the accountable owner. Mitigation: explicit decision rights, visible recommendations, owner signoff where required.
• Central-service context loss — generic output is fast but unusable. Mitigation: embedded discovery, service acceptance measures, federated domain stewards.
• Coordination tax — more handoffs, meetings, and templates than value. Mitigation: prefer self-service platforms and automate recurrent low-risk paths.
• Metric gaming — tickets close while downstream work fails. Mitigation: pair service metrics with end-to-end outcome and rework measures.
• Sensitive-data overreach — convenience expands access. Mitigation: minimum necessary access, purpose limitation, audit logs, retention rules, and human review.

Human / AI teaming

AI is well suited to retrieval, synthesis, drafting, queue monitoring, comparison, structured facilitation, record maintenance, and reminder/follow-through. Humans retain relationship work, political and moral judgment, risk acceptance, professional signoff, sensitive people decisions, negotiation, and accountability for the core outcome. Use deterministic workflow/rules for permissions, deadlines, routing, and hard controls where possible; use models for language and uncertain synthesis with evidence visible.

Adapting to any nation or organization

• Scale (city-state → federation): whether this role is unified or layered across local/regional/national tiers.
• State capacity (fragile → high-capacity): whether the owning institution exists and can be held to account, or the job is met by markets, households, NGOs, or donors.
• Income level (low → high): affordability of automation and the balance of subsistence vs. wage work.
• Formality (informal → formal): whether the people and assets this role acts on appear in any registry at all.
• Resource & geography: which hazards and dependencies dominate (water-scarce, flood-prone, landlocked, trade-dependent).
• Political system & legitimacy: where the human-accountability boundary actually binds and who may hold power to account.

Also adjust for organizational scale and topology: in a small organization one person may cover several families; in a large one, use shared platforms plus embedded/federated specialists. Informal organizations may rely on oral knowledge and relationships, so digitization must not erase legitimate local practice or create surveillance.