DP-019

Persistent Project Memory

Long running projects lose knowledge when records are fragmented across people, conversations and tools. Bound an authorised corpus, normalise and index its artefacts, preserve provenance and permissions, and support source linked retrieval through search or dialogue. Answers should expose their supporting records, uncertainty and current state. The system is a recoverable project memory, not an autonomous project manager: people decide what records mean, what actions follow and how access, correction and retention are governed.

Source manuscript

When this helps

Editorial synthesis grounded in the source pattern. Long-running projects with authorised records distributed across files, notes, meetings and contributors, where later retrieval and continuity matter.

Project history is frequently distributed across notes, emails and files, making it difficult to reconstruct decisions, responsibilities and timelines over extended periods. This fragmentation complicates onboarding, obscures accountability and requires significant effort to answer routine questions about project progress.

Pattern response

Editorial synthesis grounded in the source response. Construct a bounded project corpus with stable source identities, explicit permissions and recoverable history. Normalise and index authorised artefacts, support exact or semantic retrieval, and compose answers that expose their supporting records and uncertainty. Keep correction, access and retention governed. People decide what the records mean and what action follows.

  • A bounded, indexed and governed project corpus with stable source identities.
  • Source-linked answers and recoverable project history or state.
  • Explicit access, correction and retention controls without autonomous project decisions.

Workflow at a glance

DP-019 | Project Memory Portrait workflow diagram for Persistent Project Memory DP-019 | Project Memory
Canonical workflow · DP-019Persistent Project Memory
  1. 01

    Bound the corpus and permissions

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-001 · MOD-045 · MOD-046
  2. 02

    Ingest project artefacts

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-003 · MOD-006
  3. 03

    Extract and enrich records

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-011 · MOD-014 · MOD-013
  4. 04

    Store and index

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-037 · MOD-039
  5. 05

    Query and retrieve

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-040 · MOD-024 · MOD-023
  6. 06

    Compose grounded answers

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-007 · MOD-014 · MOD-013
  7. 07

    Review and operationalise

    An accountable academic initiates, interprets, or approves this stage; automation remains bounded by the listed modules.

    MOD-042 · MOD-044 · MOD-035

Human checkpoints

People define purpose and boundaries, supply or authorise source material, inspect intermediate representations, resolve ambiguity, approve consequential outputs, correct errors, and remain accountable for scholarly, pedagogical, legal, or organisational decisions. A generated recommendation or draft is not an approval decision.

Risks and misuse

Source-stated improvement concerns

  • Enhance structured extraction of decisions, actions and rationales so that these become primary objects within the system.
  • Introduce proactive capabilities, such as surfacing unresolved tasks, upcoming deadlines or inconsistencies across documents.
  • Develop onboarding views that generate structured summaries tailored to new participants.
  • Strengthen trust mechanisms by indicating uncertainty, distinguishing between direct quotations and summarised content, and enabling rapid access to original sources.
  • Extend analytical capabilities to identify patterns across projects, such as recurring risks or timeline deviations, to inform future planning.

Inferred workflow risks

  • Inferred: unstated constraints.
  • Inferred: scope drift.
  • Inferred: ambiguous success conditions.
  • Inferred: recording without notice.
  • Inferred: over-broad permissions.
  • Inferred: stale access.
  • Inferred: coerced consent.
  • Inferred: indefinite retention.

Use this pattern

Begin with the recurring problem and the authorised inputs. Follow the workflow in order, keep intermediate outputs inspectable and retain the named human decisions.

  • Minimum viable implementation: a documented human procedure using the ordered modules: Workflow Briefing and Context Definition → Consent and Access Control → Retention and Privacy Governance → Source and Record Ingestion → Artefact Normalisation → Metadata and Tagging → Information Extraction → Source Linking and Citation Grounding → Record Storage → Knowledge Base Indexing → Conversational Interaction → Semantic Retrieval → Keyword and Metadata Search → Summarisation → Information Extraction → Source Linking and Citation Grounding → Output Quality Evaluation → Human Review and Approval → Project State Tracking.
  • Robust implementation: add explicit schemas, source identifiers, access controls, logging, exception queues, independent evaluation, backups, and named approval owners.
  • Low-code implementation: use forms and a workflow orchestrator to connect bounded services, with approval gates before external communication or state changes.
  • Local or privacy-preserving implementation: keep sensitive artefacts in controlled storage and prefer local extraction, transcription, search, or model execution where capability and governance permit.
  • Speculative implementation: more autonomous coordination may be explored only with constrained tools, stop conditions, audit logs, and human authority; it is not implied by the source pattern.

Reusable modules

View in Atlas →

Technical and provenance detail

Data and information flow

Inputs may include request, context, constraints, identity, purpose, data classification, consent state, data inventory, policy and legal requirements, files, records, messages, source metadata, heterogeneous artefacts, target schema, artefact, metadata schema, controlled vocabulary, source content, claim or output, source corpus, location identifiers, artefact or record, metadata, retention rule, normalised corpus, index configuration, user message, dialogue state, available tools or sources, natural-language query, indexed corpus, query, indexed records, filters, summary purpose, length constraints, output, criteria, source evidence, candidate output or action, evidence, review criteria, status events, task plan, decision records. The stage sequence transforms, analyses, enriches, retrieves, generates, coordinates, stores, or outputs information according to each linked module contract. Outputs may include approved workflow brief, access decision, consent record, restrictions, retention schedule, handling rules, deletion or archive records, ingested source set, ingestion log, normalised artefacts, conversion log, enriched artefact, metadata record, structured records, source spans, confidence, grounded output, source links, support status, stored object, identifier, storage receipt, search index, index manifest, update log, response, state update, action or question, ranked source passages, similarity scores, source identifiers, ranked matching records, match metadata, summary, source references, evaluation findings, score or decision, required revisions, approval decision, corrections, rationale, escalation, project state, history, exceptions. Source identity, permission state, uncertainty, retention, and human decisions should travel with records rather than being discarded between stages.

Source provenance

  • Pattern ID: DP-019
  • Original title: Pattern 7: Project Memory GPT
  • Source location: SRC-001:P0456–P0485; page number unknown.
  • Source status: explicit.
  • Extraction notes: Canonical ID follows manuscript order. Legacy numbers are not used as publication identifiers; any numbered source heading is retained only for provenance and source fidelity.
  • Editorial interventions: The public title, summary, context, response and intended outcomes are concise editorial syntheses grounded in the source pattern. Original source prose is preserved below; workflows and modules remain separated and provenance-labelled.

Open questions

  • Which elements of this pattern require empirical or practice-based evaluation in the intended setting?
  • Which implementation examples remain current, authorised and proportionate to the setting at the time of use?