Ask, Teach, Task

Every interaction with a Knowledge Pack is one of three actions. They stay deliberately small, and compose instead of absorbing each other’s semantics.

Action	Intent	Pack cardinality	Durable effect	Complete when
Ask	“Give me an answer.”	One or more	None	A grounded answer or honest decline is returned
Teach	“Know this next time.”	Exactly one	Changes that pack’s understanding	The contribution is processed and usable by the pack
Task	“Go do this work.”	Exactly one	Creates trackable work; pack changes must be explicit	The requested result is produced, or the blocker is reported

The cardinality is deliberate:

• Reading across packs is safe and useful, so ask supports multiple packs.
• Learning needs unambiguous ownership, provenance, and conflict handling, so teach targets one pack.
• Work needs one owner, one activity history, and one permission context, so task belongs to one pack.

Ask

Ask answers a question using a read-only Ask Context: the set of one or more packs selected for that question. It makes no durable change to any selected pack, no matter how much retrieval, live reading, or multi-step computation was needed to produce the answer.

Selecting several packs for an Ask Context never merges them or widens access. Each pack keeps its own identity, permissions, and provenance, and an answer identifies which packs and sources supported it. Conflicting evidence across packs is surfaced, not silently blended.

"What does our company mean by activation?"
"Compare the Product and Sales packs' definitions of an active account."

When ask can’t answer, it tells you why — see Gap-routing for how to close that specific gap, or Declaring objectives to get ahead of it before anyone asks.

Teach

Teach makes a durable contribution or correction to exactly one pack. The target is always visible before the action is accepted, and teach is only complete once the contribution is actually usable in future asks and tasks: accepting a file isn’t enough, it has to be indexed.

Teach can take a direct statement, a correction, a file, researched material, or an Ask answer worth retaining. It always targets one pack, because durable understanding needs a clear owner: who may change it, where provenance is recorded, and which future asks and tasks can use it.

"Teach the pack that DLU excludes bot-authored pull requests."

Note

Attaching a live connection isn’t itself teaching. A connection stays a live source of truth; teach only fires when you explicitly ask the pack to retain a durable fact, summary, or rule.

Every teach returns a receipt: the target pack, what was learned, where it came from, whether it conflicted with existing material, and how to edit or undo it.

Task

A task asks exactly one pack to perform trackable work: research, curation, semantic modeling, or anything that needs more than a single retrieval step. The pack supplies the task’s source access, permission context, and activity history.

A task can use every source legitimately available through its pack (knowledge, connections, modeled data, readable upstream packs), but it cannot update an upstream or unrelated pack, and it doesn’t automatically mutate its own pack’s understanding either. These are different requests:

"Research competitor pricing and report back."          → produces a result
"Research competitor pricing and teach the findings."    → produces a result AND updates the pack

How they compose

Ask   ── "teach this"          ──▶ Teach
Ask   ── "investigate further" ──▶ Task
Task  ── "retain the findings" ──▶ Teach (same pack)
Task + schedule                ──▶ Recurring task
Recurring task + teach         ──▶ Continuously maintained pack

That last line is the core of a self-maintaining Knowledge Pack: a recurring task reads a pack’s live sources and learned definitions, produces a result, and teaches that result back into the same pack, so future asks can compare this week against every prior run.

Design constraints

A short list of rules that hold regardless of implementation:

1. Ask is always read-only.
2. Ask supports one or more readable packs; teach and task always target exactly one.
3. Task changes a pack’s understanding only through an explicit teach.
4. Selecting several packs for an Ask Context never merges them or widens access.
5. Provenance retains both source and pack identity.
6. Built-on (upstream) material is readable but never writable through the consuming pack.
7. How long something takes, or what kind of source it reads, never determines which action it is.

Next: Sources & provenance, covering what a pack can actually read from and how freshness is reported.