AIPOM Context Lifecycle Designer
What Is It
Design the operating lifecycle for purpose-specific AI context from creation through retrieval, use, feedback, correction, refresh, versioning, reconciliation, retention, expiry, exclusion, and retirement.
Why Use It
A trustworthy context package at launch becomes dangerous when sources change, corrections do not propagate, or old decisions persist without expiry. Lifecycle design makes context state and failure behavior operational.
When to Use It
Use when a context package supports recurring or production work, especially when sources, permissions, policies, or decisions change. This does not replace data retention, privacy, legal, or records-management authority.
What It Produces
- Context objects, states, transitions, and owners
- Retrieval, provenance, refresh, reconciliation, and expiry rules
- Correction, exclusion, deletion, fallback, and escalation behavior
- Monitoring, tests, change control, and review cadence
Who Should Participate
Include context consumers, source owners and stewards, workflow and technical owners, knowledge or data specialists, and privacy, security, legal, or governance partners as needed.
Evidence to Bring
Bring source maps, context packages, retrieval logs, stale or conflicting cases, permission and retention rules, correction events, incidents, change histories, and operating ownership.
How to Do It
- Define the purpose, consumer, decision, consequence, and context boundary.
- Inventory context objects, authoritative sources, derivations, versions, and owners.
- Define states such as draft, approved, active, disputed, stale, expired, restricted, and retired.
- Specify creation, approval, retrieval, refresh, reconciliation, correction, exclusion, expiry, and deletion transitions.
- Define provenance, timestamps, confidence, conflict, and missing-context signals shown at use.
- Set retention and access rules with accountable specialists.
- Design fallback and escalation when context is missing, stale, disputed, or inaccessible.
- Define monitoring for retrieval quality, staleness, conflict, correction propagation, and unauthorized use.
- Test representative state changes and assign review triggers.
Key Concepts
- Context state should change system behavior.
- Correction must propagate to derived artifacts.
- Newest is not always authoritative.
- Retention and retrieval serve different decisions.
Organizational Applications
Use for product knowledge, policy retrieval, research evidence, customer context, decision histories, workflow playbooks, and agent memory.
Common Pitfalls
- Designing retrieval without expiry
- Treating timestamps as trust
- Updating sources without derived context
- Retaining everything because it may be useful
- Omitting disputed and restricted states
- Assigning stewardship without monitoring or correction duties
Combine With
Use aipom-data-readiness-audit for data fitness, aipom-workflow-playbook-builder to embed context behavior in work, and aipom-production-evidence-review to inspect lifecycle performance.
Assets and Templates
- Context lifecycle template
- Synthetic worked example
- Weak example
Sources
This skill is an original AIPOM synthesis of context engineering, knowledge governance, data lifecycle, and operational reliability practice.
1---2name: aipom-context-lifecycle-designer3description: Design how AI context is created, retrieved, refreshed, versioned, reconciled, retained, expired, excluded, and retired for a recurring purpose.4---56# AIPOM Context Lifecycle Designer78## What Is It910Design the operating lifecycle for purpose-specific AI context from creation through retrieval, use, feedback, correction, refresh, versioning, reconciliation, retention, expiry, exclusion, and retirement.1112## Why Use It1314A trustworthy context package at launch becomes dangerous when sources change, corrections do not propagate, or old decisions persist without expiry. Lifecycle design makes context state and failure behavior operational.1516## When to Use It1718Use when a context package supports recurring or production work, especially when sources, permissions, policies, or decisions change. This does not replace data retention, privacy, legal, or records-management authority.1920## What It Produces2122- Context objects, states, transitions, and owners23- Retrieval, provenance, refresh, reconciliation, and expiry rules24- Correction, exclusion, deletion, fallback, and escalation behavior25- Monitoring, tests, change control, and review cadence2627## Who Should Participate2829Include context consumers, source owners and stewards, workflow and technical owners, knowledge or data specialists, and privacy, security, legal, or governance partners as needed.3031## Evidence to Bring3233Bring source maps, context packages, retrieval logs, stale or conflicting cases, permission and retention rules, correction events, incidents, change histories, and operating ownership.3435## How to Do It36371. Define the purpose, consumer, decision, consequence, and context boundary.382. Inventory context objects, authoritative sources, derivations, versions, and owners.393. Define states such as draft, approved, active, disputed, stale, expired, restricted, and retired.404. Specify creation, approval, retrieval, refresh, reconciliation, correction, exclusion, expiry, and deletion transitions.415. Define provenance, timestamps, confidence, conflict, and missing-context signals shown at use.426. Set retention and access rules with accountable specialists.437. Design fallback and escalation when context is missing, stale, disputed, or inaccessible.448. Define monitoring for retrieval quality, staleness, conflict, correction propagation, and unauthorized use.459. Test representative state changes and assign review triggers.4647## Key Concepts4849- Context state should change system behavior.50- Correction must propagate to derived artifacts.51- Newest is not always authoritative.52- Retention and retrieval serve different decisions.5354## Organizational Applications5556Use for product knowledge, policy retrieval, research evidence, customer context, decision histories, workflow playbooks, and agent memory.5758## Common Pitfalls5960- Designing retrieval without expiry61- Treating timestamps as trust62- Updating sources without derived context63- Retaining everything because it may be useful64- Omitting disputed and restricted states65- Assigning stewardship without monitoring or correction duties6667## Combine With6869Use `aipom-data-readiness-audit` for data fitness, `aipom-workflow-playbook-builder` to embed context behavior in work, and `aipom-production-evidence-review` to inspect lifecycle performance.7071## Assets and Templates7273- [Context lifecycle template](template.md)74- [Synthetic worked example](examples/worked-example.md)75- [Weak example](examples/weak-example.md)7677## Sources7879This skill is an original AIPOM synthesis of context engineering, knowledge governance, data lifecycle, and operational reliability practice.
Dean Peters