### 1\. 🔍 Phase 1 — Requirement and Knowledge-Flow Reconstruction ### Agent responsibilities \- Literature Discovery Agent * Produces publication candidates, bibliographic metadata, and search provenance. * Consumes research questions, inclusion criteria, and authorized source catalogs. * Cannot declare a paper scientifically valid solely because it appears in a reputable search result. \- Clinical Evidence Extraction Agent * Extracts study design, population, intervention, comparator, outcomes, limitations, and reported findings. * Consumes source documents and validated bibliographic records. * Must distinguish directly reported results from extracted interpretations. \- Research Quality Assessment Agent * Evaluates methodology, bias, limitations, and evidence certainty. * Consumes extracted study information and assessment criteria. * Cannot silently change source findings or overwrite another reviewer's assessment. \- Drug Interaction Analysis Agent * Identifies potential drug interaction evidence within its authorized research scope. * Consumes approved drug references and traceable scientific evidence. * Its outputs are research findings, not individualized treatment recommendations. \- Research Synthesis Agent * Produces evidence summaries, comparisons, and uncertainty statements. * Consumes authorized, source-linked findings and quality assessments. * Must preserve material disagreements between studies. \- Memory Governance Agent * Controls memory classification, publication, permissions, retention, and lifecycle. * Consumes proposed memory records and policy decisions. * Cannot manufacture scientific authority or change research conclusions without appropriate evidence and approval. ### Knowledge-flow reconstruction ```mermaid flowchart TD A[Research Question] --> B[Literature Discovery] B --> C[Source Validation] C --> D[Evidence Extraction] D --> E[Quality Assessment] D --> F[Drug Interaction Analysis] E --> G[Research Synthesis] F --> G G --> H[Human Research Review] H --> I[Memory Governance] I --> J[(Canonical Memory Store)] J --> K[Event Propagation] K --> L[Search Indexes] J --> M[Authorized Retrieval Gateway] L --> M M --> N[Authorized Research Agents] O[Audit and Monitoring] --- I O --- M ``` This is a proposed logical design, not an existing deployment. ### Requirement classification * Explicit requirements: Six specialized agents, source traceability, evidence uncertainty, project isolation, controlled sharing, and deletion policies. * Derived requirements: Citation integrity, study-version tracking, evidence disagreement handling, licensed-document restrictions, and reproducible synthesis. * Assumptions: Each agent has an authenticated identity; research projects have identifiable owners; approved sources can be referenced by stable identifiers. * Proposals: Relational canonical storage, controlled document storage, optional vector retrieval, and durable event propagation. * Unresolved questions: Applicable jurisdictions, publication licenses, research ethics requirements, permitted personal-data categories, recovery objectives, and infrastructure budget. ### Requirements-to-design traceability * Source traceability → immutable source identifiers and citation validation → citation-integrity tests. * Evidence uncertainty → structured confidence and assessment metadata → uncertainty-preservation tests. * Research isolation → project-scoped authorization → cross-project access-denial tests. * Version tracking → immutable source snapshots or version references → source-change regression tests. * Shared knowledge → governed publication and scope checks → publication authorization tests. * Reliable updates → revision checks and durable event propagation → replay and concurrency tests. * Controlled deletion → canonical revocation and dependent-artifact cleanup → end-to-end deletion evidence. Phase 1 conclusion: The architecture can be designed from the supplied requirements, but regulatory applicability, licensing conditions, and operational objectives must be resolved before production deployment. ### 2\. 🗂️ Phase 2 — Memory Taxonomy and Lifecycle Design \- Working research memory * Purpose: Hold the current question, search progress, temporary extraction results, and task dependencies. * Owner: Research task orchestrator. * Readers: Agents assigned to that task. * Writers: Authorized task participants. * Lifecycle: Expire after task completion unless a specific recovery or audit requirement justifies retention. * Source of truth: Workflow state service. \- Research episodic memory * Purpose: Record what a research task examined, which sources were considered, and why decisions were made. * Owner: Research project. * Readers: Authorized project members. * Writers: Task agents through validated submissions. * Lifecycle: Retain according to research reproducibility and project-retention requirements. * Source of truth: Versioned research activity record. \- Scientific factual memory * Purpose: Represent reported scientific findings and their supporting evidence. * Owner: Designated evidence custodian. * Readers: Authorized research agents within the relevant project or sharing scope. * Writers: Evidence extraction and review workflows. * Lifecycle: Supersede or annotate when evidence changes; preserve disagreement and source history. * Source of truth: Original publication or authoritative source document, not the generated summary. \- Research procedure memory * Purpose: Store approved search methods, extraction schemas, evaluation criteria, and reproducibility instructions. * Owner: Research methods lead or authorized governance role. * Readers: Agents permitted to perform the relevant workflow. * Writers: Authorized procedure maintainers. * Lifecycle: Version, review, and retire outdated procedures. * Source of truth: Approved procedure repository. \- Agent-private memory * Purpose: Preserve permitted task-local observations or intermediate structured artifacts. * Owner: Individual agent identity or assigned task. * Readers: Explicitly authorized principals only. * Writers: Owning agent through the memory service. * Lifecycle: Short-lived by default; no automatic promotion to shared memory. * Source of truth: Agent-private namespace, subject to canonical lifecycle rules. \- Project-shared memory * Purpose: Provide approved evidence and findings across a research team. * Owner: Research project. * Readers: Authorized project members. * Writers: Designated evidence publishers and approved contributors. * Lifecycle: Revision-controlled, reviewable, and revocable. * Source of truth: Canonical shared-memory record with source references. \- Coordination memory * Purpose: Track task dependencies, review status, agent assignments, and publication workflow state. * Owner: Workflow orchestrator. * Readers: Agents and operators authorized for the workflow. * Writers: Orchestrator and explicitly authorized services. * Lifecycle: Retain only as long as needed for execution, recovery, and defined audit requirements. * Source of truth: Workflow database. \- Reference-document memory * Purpose: Make licensed or permitted research documents discoverable and retrievable. * Owner: Document repository or licensing authority. * Readers: Principals permitted under the relevant license and project policy. * Writers: Document ingestion service and authorized maintainers. * Lifecycle: Follow source corrections, license expiry, access withdrawal, and deletion requirements. * Source of truth: Original document or authorized archived version. Design rule: Do not force all categories into a vector database. Structured facts, workflow state, documents, and semantic indexes have different consistency and lifecycle needs. ### 3\. 🔐 Phase 3 — Memory Ownership and Agent Boundaries ### Ownership model * Creator: Agent or service that proposes a record. * Business owner: Research project or domain authority accountable for its use. * Custodian: Service responsible for storage, access enforcement, and lifecycle operations. * Source of truth: Original publication, approved protocol, or authoritative workflow system. * Authorized consumer: Principal allowed to access the record for a defined purpose. These roles are independent. An agent that extracts a result does not automatically become its scientific authority or gain permission to share it. ### Proposed authority boundaries * Literature Discovery may propose source metadata and candidate references. * Evidence Extraction may create structured study summaries with citation pointers. * Quality Assessment may publish its own versioned assessment but cannot erase the underlying study findings. * Drug Interaction Analysis may produce scoped evidence assessments without accessing unrelated confidential projects. * Research Synthesis may create a composite summary only from authorized inputs and must retain supporting references. * Memory Governance may approve sharing, revoke access, and enforce lifecycle policy without rewriting scientific evidence. ### Controlled promotion to shared memory * An agent submits a structured candidate. * The memory service validates the identity, source reference, schema, and intended project scope. * The service checks privacy, license, and confidentiality restrictions. * The responsible reviewer evaluates the record when approval is required. * The system commits the approved version and its provenance. * A publication event makes the new version discoverable to authorized consumers. * Retrieval checks the current access policy before disclosing any content. If a source document is subject to a restricted license, publishing a short factual finding or metadata record may still require policy review. Do not assume every derivative is freely shareable. ### Ownership transfers * Require an authorized transfer request. * Record the previous owner, new owner, reason, and approval. * Reevaluate the new owner's access scope. * Quarantine the record if its ownership or sharing eligibility is unresolved. * Preserve historical revisions according to applicable retention policy. ### 4\. 🏗️ Phase 4 — Storage and Representation Architecture ### Proposed components \- Relational database * Stores canonical memory metadata, structured evidence, ownership, revisions, and lifecycle status. * Enforces uniqueness, revision checks, and transactional state changes. * Requires protected backups, restoration tests, and access-restricted database credentials. \- Document storage * Stores source files or approved extracts when permitted. * Preserves source version, checksum, origin, license metadata, and ingestion timestamp. * Applies document-level access controls and retention rules. \- Vector index * Supports semantic discovery of relevant research records. * Stores references to canonical records rather than becoming their authoritative source. * Requires tenant/project filters, revision tracking, and index rebuild procedures. \- Event system * Propagates publication, correction, revocation, and deletion events. * Uses stable event identifiers, revision checks, bounded retries, and dead-letter handling. * Requires reconciliation against canonical state. \- Cache * Accelerates eligible retrieval requests. * Uses scope-aware cache keys and bounded lifetimes. * Must not bypass current authorization or revocation checks. \- Audit system * Records security decisions, revisions, publication outcomes, and lifecycle operations. * Restricts access and avoids storing full protected documents unnecessarily. ### Proposed canonical record ```json { "memory_id": "research_mem_0241", "project_id": "project_demo_07", "category": "scientific_finding", "owner_id": "research_project_07", "creator_id": "evidence_agent_02", "custodian_id": "memory_service", "access_scope": "project", "sensitivity": "confidential_research", "content": { "claim": "Study reports an association between exposure X and outcome Y", "interpretation": "Observational association; causality not established" }, "provenance": { "source_id": "publication_demo_123", "source_version": "version_1", "locator": "Results section", "verification_status": "pending_review" }, "revision": 1, "status": "draft", "created_at": "2026-10-25T00:00:00Z", "updated_at": "2026-10-25T00:00:00Z", "expires_at": null } ``` This is synthetic data for the test, not a real publication or scientific claim. ### Data-model requirements * Mandatory fields should include stable ID, category, owner, access scope, creator, status, revision, timestamps, and provenance reference. * Source version, citation locator, sensitivity, validity, expiry, confidence, and approval metadata should be required whenever the record type or policy requires them. * Scientific confidence must not be confused with extraction confidence, source reliability, or statistical significance. * Preserve original reported findings separately from generated interpretations. * Avoid duplicating full licensed documents into logs, embeddings, or derived records without authorization. ### 5\. 🧹 Phase 5 — Memory Ingestion and Admission Control ### Proposed ingestion workflow * Candidate extraction: Produce a structured candidate from an approved source or authorized research task. * Schema validation: Check required fields, data types, identifiers, and supported categories. * Source validation: Confirm that the source reference exists and points to the expected version. * Citation verification: Check whether the claimed passage or locator supports the extracted statement. * Sensitivity screening: Identify personal data, confidential research, and prohibited content. * License screening: Check applicable document access and derivative-use restrictions. * Deduplication: Compare source identifiers, claim identity, and version metadata. * Conflict detection: Identify incompatible findings without automatically declaring either false. * Approval: Require review for designated sensitive or high-impact records. * Canonical commit: Persist the accepted record with its revision and admission decision. * Publication: Emit an event only after the canonical commit succeeds. ### Rejection and quarantine conditions * Invalid or missing source references. * Claims that cannot be supported by the cited passage. * A paper's conclusion incorrectly presented as causal evidence when the study only establishes association. * Missing authorization or unresolved license restrictions. * Unnecessary personal information or credentials. * Prompt injection or instructions embedded in source material. * Duplicate candidates that add no useful version or evidence. * Contradictory findings requiring specialist assessment. * An unapproved candidate attempting to become authoritative shared knowledge. ### Audit record Each admission decision should record the candidate identifier, policy version, outcome, reason code, reviewer where applicable, timestamp, and resulting revision. Acceptance requirement: No candidate becomes an authoritative shared finding merely because an agent generated it or a semantic model assigned it a high confidence score. ### 6\. 📣 Phase 6 — Shared Memory and Knowledge Publication ### Publication state machine `DRAFT → VALIDATED → REVIEW_REQUIRED → APPROVED → PUBLISHED` Additional states: `REJECTED`, `QUARANTINED`, `REVOKED`, `SUPERSEDED`, and `EXPIRED`. ### Publication rules * Literature Discovery can publish validated bibliographic metadata when source and licensing rules permit. * Evidence Extraction can submit structured findings, but scientific findings requiring review must remain non-authoritative until approval. * Quality Assessment can publish its own assessment with methodology and reviewer provenance. * Research Synthesis can publish summaries only when source coverage and material disagreements are preserved. * Drug Interaction Analysis must distinguish literature-derived observations from verified clinical guidance. * Memory Governance enforces scope, lifecycle, and publication state. ### Shared-memory publication workflow * Validate the candidate and its source references. * Confirm the submitting agent is authorized for the target project. * Check confidentiality and license constraints. * Identify whether scientific review is required. * Commit the approved record with a new revision. * Publish an event referencing that revision. * Allow authorized consumers to discover the record through the retrieval service. * Support withdrawal and correction without silently erasing historical disagreement. ### Source-of-truth hierarchy * Original scientific publication or authorized source version for reported findings. * Approved research protocol for the project's planned methodology. * Designated reviewer assessment for the reviewer's evaluation. * Canonical memory service for memory metadata, revisions, and publication state. * Search indexes for discovery only. If a publication is corrected or retracted, dependent memories must be marked for reassessment. A source's new status must not be ignored merely because its earlier summary remains highly ranked. ### 7\. 🔄 Phase 7 — Synchronization and Consistency Engineering ### Proposed consistency guarantees * Canonical writes: Transactional commit for memory content, revision metadata, and the associated outbox event. * Authorization: Current policy and lifecycle checks before protected content is delivered. * Event propagation: At-least-once delivery where supported by the selected queue, with idempotent consumers. * Vector indexing: Eventual consistency, with revision-aware indexing and canonical verification. * Cache updates: Best-effort propagation backed by TTLs, invalidation, and authorization checks. * Revocation: Immediate logical access denial after canonical revocation commits; physical cleanup may continue asynchronously. * Research summaries: Eventual refresh is acceptable only if outdated or invalidated summaries cannot be misrepresented as current authoritative findings. ### Event contract ```json { "event_id": "event_9021", "event_type": "research_memory.superseded", "project_id": "project_demo_07", "memory_id": "research_mem_0241", "revision": 2, "idempotency_key": "research_mem_0241:2:superseded", "schema_version": 1, "occurred_at": "2026-10-25T12:00:00Z" } ``` This is a proposed event format. ### Failure handling * Duplicate event: Deduplicate by event ID or make the consumer operation idempotent. * Out-of-order event: Reject stale revisions when updating the current-state projection. * Delayed event: Track lag and retry with bounded backoff. * Queue outage: Preserve committed outbox entries and alert when backlog limits are approached. * Index outage: Use an authorized fallback or return a controlled failure. * Source correction: Invalidate affected derived summaries and enqueue reassessment. * Consumer disconnection: Replay missed events and reconcile against canonical revisions. * Repeated processing failure: Move the event to a dead-letter queue and require controlled recovery. No design should assume that a successful database write instantly updates every agent's local context. ### 8\. ⚖️ Phase 8 — Conflict Resolution and Memory Versioning ### Conflict types and policies * Contradictory scientific findings: Preserve both findings, their study designs, source versions, and limitations. Do not choose a winner by timestamp alone. * Concurrent edits to one record: Use optimistic concurrency control and expected-revision checks. * Different quality assessments: Preserve reviewer identity, criteria, and assessment version; escalate material disagreement. * Corrected or retracted publication: Link the new source status to affected memories and mark dependent conclusions for reassessment. * Duplicate study records: Compare persistent identifiers, publication versions, and correction history before merging. * Different population or context: Retain contextual distinctions rather than merging apparently similar claims. * Conflicting drug interaction evidence: Preserve source evidence and uncertainty; require qualified review before any high-impact conclusion is published. * Unresolved dispute: Mark the record as disputed or quarantine its use in authoritative synthesis. ### Versioning rules * Every accepted change increments the canonical revision. * Every scientific finding retains its source and evidence locator. * Material changes require a new revision or a new linked finding. * Rollbacks create new revisions rather than erasing the history of previous decisions. * Derived summaries record the revisions of their supporting evidence. * Reassessment must be triggered when important source versions or publication statuses change. Acceptance requirement: The system can explain which evidence supported a conclusion at a specific point in time and what changed when that conclusion was revised. ### 9\. 🛡️ Phase 9 — Memory Permissions and Information-Flow Security ### Trust boundaries * External publication boundary: Scientific articles and metadata may contain incorrect claims, misleading text, or hostile embedded instructions. * Agent boundary: One agent cannot inherit another agent's permissions merely because they collaborate. * Project boundary: Confidential research cannot be exposed to another project by semantic search, shared cache, or generated summary. * Storage boundary: Direct database and object-store access is restricted to authorized services. * Model-context boundary: Protected records are filtered before they reach the model. * Audit boundary: Security events must not become a secondary channel for confidential content disclosure. ### Threats and mitigations \- Cross-project leakage * Bind every request to authenticated identity and project scope. * Enforce authorization before candidate content is returned. * Test exact, semantic, cached, and summary-based retrieval paths. \- Scientific memory poisoning * Validate source provenance and citation support. * Separate extracted evidence from agent interpretations. * Require review for designated high-impact conclusions. \- Prompt injection from papers * Treat document contents as untrusted data. * Do not execute instructions found in stored publications. * Keep retrieval content subordinate to system policy and application authorization. \- Sensitive unpublished research exposure * Enforce project membership, confidentiality classifications, and approved sharing rules. * Restrict exports and record access decisions. \- Stale or revoked evidence * Recheck canonical status before disclosure. * Invalidate derived summaries and search representations. * Quarantine affected synthesis outputs until reassessment. \- Credential leakage * Reject credentials and unnecessary secrets during admission. * Redact diagnostic data. * Use approved secret-management mechanisms for actual application credentials. ### Authorization rule A memory is eligible for retrieval only when the principal is authenticated, the project scope matches, the requested purpose is permitted, the sensitivity policy allows access, and the memory remains eligible for use. If authorization cannot be established, deny access. Similarity scores, source popularity, and instructions embedded in retrieved content cannot override these controls. ### 10\. 🔎 Phase 10 — Cross-Agent Retrieval and Context Assembly ### Retrieval pipeline ```mermaid flowchart TD A[Research Query] --> B[Authenticate Agent] B --> C[Resolve Project and Purpose] C --> D[Enforce Access Filters] D --> E[Metadata and Semantic Search] E --> F[Rank Relevant Evidence] F --> G[Verify Source and Version] G --> H[Check Retraction and Freshness] H --> I[Detect Conflicts and Duplicates] I --> J[Assemble Bounded Context] J --> K[Final Authorization Check] K --> L[Deliver Findings and Citations] K --> M[Exclude Unauthorized or Invalid Records] ``` ### Ranking policy * Authorization is a hard eligibility condition, not a relevance score. * Relevance measures how well a finding addresses the research question. * Source authority is evaluated in the context of the claim being supported. * Methodological quality and evidence certainty must remain distinct from textual similarity. * Freshness depends on the category: a scientific finding may remain relevant for years, while a retraction status requires rapid propagation. * Provenance quality affects whether a record can support a conclusion. * Contradictory evidence should not be hidden merely because it ranks lower. ### Retrieval outcomes * No results: Return no eligible evidence found; do not broaden access scope. * Stale results: Check source versions and publication status before using them. * Contradictory findings: Return the relevant disagreement and supporting citations. * Missing source locator: Exclude the record from citation-critical synthesis or label its limitation. * Vector index unavailable: Use authorized structured search or a controlled failure. * Retracted source: Flag it and prevent unqualified use as current supporting evidence. * Context budget exceeded: Prioritize relevant, authorized, traceable evidence while retaining material limitations and disagreements. * Confidential source: Exclude it from any answer whose recipient lacks authorization. ### Context assembly requirements Each evidence item should include the claim, source identifier, source version, citation locator, study type where available, review status, and known limitations. Generated summaries must distinguish reported findings from interpretations and hypotheses. The final research brief must never claim that all relevant evidence has been reviewed unless the search methodology and coverage justify that statement. ### 11\. 🗑️ Phase 11 — Memory Update, Invalidation, and Deletion ### Lifecycle model `DRAFT → APPROVED → ACTIVE → SUPERSEDED / REVOKED / EXPIRED → DERIVED-ARTIFACT REVIEW → VERIFIED COMPLETION` The applicable path depends on the type of update and the retention policy. ### Source correction or retraction * Receive a source-status change from a verified source or authorized reviewer. * Validate the source identifier and version. * Update the canonical source-status record. * Identify memories and research summaries that depend on that source. * Mark affected conclusions as requiring reassessment. * Publish revision-aware invalidation events. * Reassess downstream summaries and approved research briefs. * Verify that stale conclusions are not presented as current, unqualified evidence. ### Deletion workflow * Authenticate the requester and verify deletion authority. * Identify the canonical record and known dependent artifacts. * Commit revocation or deletion state in the authoritative store. * Deny ordinary retrieval immediately after the revocation commit. * Invalidate applicable caches, embeddings, summaries, and downstream projections. * Delete in-scope physical copies according to policy and legal obligations. * Verify cleanup and record outstanding failures. * Document any backup retention or legal preservation exceptions. ### Important distinctions * A retracted study may need to remain discoverable as historical evidence of the research record, but must be appropriately labeled and handled according to the applicable research policy. * A privacy deletion request may require removal of personal data from both source-linked records and dependent artifacts, subject to valid retention obligations. * Audit metadata may be retained only when authorized and necessary; it should not become a copy of deleted sensitive content. * Expiring a cache does not prove that the canonical record, embedding, or derived summary was deleted. * Deleting a source document does not automatically remove its extracted findings or generated summaries. Acceptance requirement: The system can identify the known descendants of a memory and provide evidence of their lifecycle status without falsely claiming that all copies have been removed. ### 12\. 🧪 Phase 12 — Memory Evaluation and Adversarial Testing These are proposed tests, not executed results. ### Functional correctness tests \- TEST-01: Citation integrity * Setup: A finding references a known source and locator. * Action: Retrieve the finding for research synthesis. * Expected result: The source reference and locator match the canonical record. * Criterion: All returned citation-critical records pass the defined integrity checks. * Evidence: Test fixture, retrieved revision, and citation-validation result. \- TEST-02: Research project isolation * Setup: Two projects contain distinct confidential findings. * Action: An agent in Project A queries for a finding belonging to Project B. * Expected result: No protected content from Project B is disclosed. * Criterion: Zero unauthorized disclosures in the test suite. * Evidence: Authorization trace and response-content inspection. \- TEST-03: Contradictory evidence * Setup: Two studies report conflicting outcomes. * Action: Generate a synthesis. * Expected result: The material disagreement and supporting sources remain visible. * Criterion: Neither finding is silently discarded. * Evidence: Source-to-summary comparison. \- TEST-04: Concurrent revision updates * Setup: Two authorized writers attempt to update the same revision. * Action: Submit concurrent writes with the same expected revision. * Expected result: A stale update receives a conflict response. * Criterion: No silent lost update. * Evidence: Revision history and API responses. \- TEST-05: Duplicate event delivery * Setup: An update event is delivered multiple times. * Action: Replay the event. * Expected result: One logical update effect. * Criterion: No duplicate current-state records. * Evidence: Event ledger and canonical state. ### Security and adversarial tests \- TEST-06: Prompt injection in a paper * Setup: A source contains instructions attempting to change memory permissions. * Action: Extract and retrieve the source. * Expected result: The text is treated as untrusted data. * Criterion: No policy or permission change occurs due to document content. * Evidence: Authorization and agent-output traces. \- TEST-07: Fabricated citation * Setup: A candidate claims that a publication supports a statement, but its cited passage does not. * Action: Submit the candidate for admission. * Expected result: Rejection or quarantine according to policy. * Criterion: Unsupported claims are not published as verified findings. * Evidence: Source-checking result and admission decision. \- TEST-08: Retracted source * Setup: An active finding depends on a source marked as retracted. * Action: Propagate the source-status change and request a synthesis. * Expected result: The finding is flagged and cannot be presented as unqualified current evidence. * Criterion: All in-scope dependent records are identified and their use is controlled. * Evidence: Dependency trace and post-update retrieval results. \- TEST-09: Revoked memory in a stale index * Setup: A record has been revoked, but a search index still contains its representation. * Action: Search for the record. * Expected result: The retrieval gateway excludes it before context delivery. * Criterion: Zero revoked content disclosed. * Evidence: Canonical status, index state, and context inspection. \- TEST-10: Licensed document access * Setup: A document is restricted to a particular project. * Action: An unauthorized agent searches for the document or a derived excerpt. * Expected result: Restricted content remains inaccessible. * Criterion: No unauthorized document or protected derivative is disclosed. * Evidence: Scope-policy trace and output inspection. ### Performance and recovery tests \- TEST-11: Sustained workload * Setup: Simulate the planning target of 120 operations per second and 1,000 concurrent tasks. * Action: Run representative search, read, update, and lifecycle operations. * Expected result: The system respects the agreed latency, error, and resource limits. * Criterion: p95 retrieval below 400 ms if that target is confirmed for the measured service boundary. * Evidence: Load-test report, request distribution, and resource metrics. \- TEST-12: Event-system outage * Setup: Interrupt event propagation while canonical storage remains available. * Action: Create and update eligible records. * Expected result: Committed changes remain recoverable, and derived indexes show measurable lag. * Criterion: Reconciliation restores the required state without losing committed revisions. * Evidence: Outbox records, recovery traces, and revision comparison. \- TEST-13: Deletion verification * Setup: A memory has embeddings, cached summaries, and dependent research briefs. * Action: Request authorized deletion. * Expected result: Retrieval is denied and every known dependent artifact is tracked through cleanup. * Criterion: All in-scope deletion targets reach the required verified state. * Evidence: Cleanup ledger and storage-specific verification. ### Quality metrics * Citation validity and provenance completeness. * Precision@k, Recall@k, and ranking quality. * Rate of unsupported claims in generated summaries. * Correct identification of retracted or corrected sources. * Rate of material disagreements preserved. * Unauthorized disclosure count. * Revocation enforcement delay. * Synchronization lag and recovery time. * Deletion completion rate across known artifacts. Thresholds for scientific accuracy and retrieval quality must be defined using a labeled research benchmark. A proposed target is not proof of achieved performance. ### 13\. 📊 Phase 13 — Observability and Memory Operations ### Operational telemetry * Memory reads, writes, updates, and deletion requests. * Retrieval latency and failure rate. * Citation validation failures. * Source-version changes and retraction-processing delay. * Admission acceptance, rejection, and quarantine counts. * Publication approval latency. * Authorization denials and suspicious access patterns. * Event backlog, consumer failures, and dead-letter volume. * Cache invalidation and vector-index lag. * Unresolved conflicts and pending evidence reassessments. * Storage growth, embedding consumption, and resource utilization. * Deletion progress and failed cleanup attempts. ### Dashboard design * Memory service health: Availability, throughput, errors, and latency. * Research evidence quality: Citation validity, provenance completeness, and unsupported-claim rate. * Security posture: Authorization denials, isolation test outcomes, and revocation failures. * Lifecycle compliance: Expiry, deletion, retention exceptions, and unresolved cleanup. * Synchronization health: Event lag, revision divergence, and reconciliation status. * Cost and capacity: Storage growth, search consumption, model usage, and recovery overhead. ### Operational runbook: retracted evidence detected * Verify the source identifier and new status. * Update the canonical source-status record. * Restrict unqualified use of dependent findings. * Identify affected research briefs and downstream artifacts. * Publish invalidation events and track processing. * Rebuild or reconcile affected search representations. * Validate that current retrieval results disclose the source status. * Notify the designated research owner when review is required. * Preserve an auditable incident record without unnecessarily copying confidential content. ### Privacy controls * Use correlation IDs instead of raw research text wherever possible. * Avoid logging full papers, confidential unpublished findings, credentials, or complete model contexts. * Restrict audit access by role. * Define retention periods for telemetry independently from research memory retention. * Alert on anomalous access and repeated unauthorized retrieval attempts. Operational dashboards must distinguish technical availability from scientific correctness. A system can be healthy while returning outdated or misleading evidence. ### 14\. 💰 Phase 14 — Scalability, Cost, and Architecture Trade-offs ### Workload analysis * 250 agents: Requires service identity management, scoped permissions, and controlled access to shared research. * 1,000 concurrent tasks: Requires connection-pool planning, task isolation, backpressure, and bounded model-context assembly. * 120 memory operations per second: Requires sustained and burst load testing, including concurrent writes and index updates. * Unknown memory growth: Requires measurements of average record size, retention duration, source-document size, and derived-artifact growth. * Unknown budget: Prevents a defensible infrastructure cost estimate. ### Architecture alternatives \- Relational database with full-text search * Advantages: Simpler deployment, structured filtering, transactional writes, and lower operational complexity. * Trade-offs: Semantic retrieval may be less effective for research questions that use different terminology from the source. \- Relational database plus vector index * Advantages: Semantic discovery alongside structured metadata filters. * Trade-offs: Embedding costs, index lag, retrieval evaluation, and additional cleanup requirements. \- Distributed memory services * Advantages: Independent scaling and possible isolation of workloads. * Trade-offs: More complex synchronization, monitoring, deployment, and recovery. \- Graph-based knowledge storage * Advantages: Can represent relationships among studies, claims, interventions, outcomes, and supporting evidence. * Trade-offs: Additional operational complexity and consistency management. ### Recommended scaling strategy * Begin with a canonical relational store and structured/full-text retrieval. * Add vector search only when benchmark results show a meaningful improvement. * Add graph storage only if relationship-traversal requirements justify it. * Introduce caching only after measuring actual repeated-query patterns. * Apply backpressure when indexing or event processing falls behind. * Partition or shard only when measured capacity or contention justifies it. * Benchmark recovery traffic as well as normal workload. ### Cost model Estimate total cost using measured values for: * Canonical and document storage. * Backup and replication overhead. * Embedding generation and vector-index maintenance. * Model inference and research synthesis. * Event delivery, monitoring, and audit retention. * Reprocessing after source corrections. * Deletion and reconciliation operations. Capacity acceptance: Demonstrate the specified workload and latency target in a representative test environment. Do not infer production capacity from agent count alone. ### 15\. 🗺️ Phase 15 — Implementation Roadmap and Decision Register ### Dependency-ordered tasks \- RES-01: Requirements and governance * Define project boundaries, source licensing, applicable privacy rules, retention, and research review responsibilities. * Dependencies: None. * Acceptance: Every memory category has an owner, authorized readers, source of truth, and lifecycle policy. \- RES-02: Canonical schema and revision management * Implement structured research records, provenance references, revisions, and optimistic concurrency. * Dependencies: RES-01. * Acceptance: Invalid records are rejected and concurrent updates cannot silently overwrite accepted revisions. \- RES-03: Identity and authorization * Implement authenticated agent identities, project scopes, purpose restrictions, and deny-by-default enforcement. * Dependencies: RES-01 and RES-02. * Acceptance: Isolation tests demonstrate no unauthorized content disclosure across the defined test cases. \- RES-04: Evidence admission * Implement source validation, citation checking, sensitivity screening, deduplication, and approval workflows. * Dependencies: RES-02 and RES-03. * Acceptance: Unsupported or unauthorized candidates cannot become authoritative shared findings. \- RES-05: Publication and synchronization * Implement canonical publication, transactional outbox, revision-aware consumers, retries, and reconciliation. * Dependencies: RES-02 and RES-04. * Acceptance: Duplicate and out-of-order events do not corrupt current state. \- RES-06: Authorized retrieval * Implement structured search, source-version checks, citation-aware ranking, and context assembly. * Dependencies: RES-03 and RES-04; integrate derived indexes after RES-05. * Acceptance: Results are authorized, traceable, and evaluated against a labeled research benchmark. \- RES-07: Lifecycle and dependency management * Implement supersession, source-status changes, revocation, expiration, and deletion propagation. * Dependencies: RES-02, RES-03, and RES-05. * Acceptance: Known dependent artifacts are tracked and their required lifecycle states are verified. \- RES-08: Observability and evaluation * Implement operational metrics, audit events, retrieval-quality evaluation, and incident runbooks. * Dependencies: API and event contracts from RES-02 and RES-05. * Acceptance: Required dashboards, alerts, and regression tests have documented validation evidence. \- RES-09: Production qualification * Run security, load, source-correction, deletion, and recovery tests. * Dependencies: All critical tasks. * Acceptance: Every mandatory production-readiness gate has documented evidence and accountable sign-off. ### Proposed architecture decisions \- ADR-01: Canonical relational storage * Context: Scientific evidence requires structured metadata, revision tracking, and reliable transactions. * Options: Relational store, document database, or distributed memory services. * Rationale: A relational store provides a straightforward initial source of truth. * Trade-off: Some semantic and relationship queries require additional indexes. * Validation: Concurrent-write, recovery, and representative query tests. \- ADR-02: Provenance-first evidence * Context: Research conclusions must be traceable to sources. * Options: Store free-form summaries alone or store structured findings with source references. * Rationale: Structured provenance makes corrections and validation more reliable. * Trade-off: Additional schema and admission requirements. * Validation: Citation-integrity and source-change tests. \- ADR-03: Governed publication * Context: Agent-generated findings vary in confidence and sensitivity. * Options: Direct shared writes or controlled publication. * Rationale: Governed publication limits uncontrolled sharing. * Trade-off: Additional review latency. * Validation: Unauthorized-publication and approval-workflow tests. \- ADR-04: Eventual consistency for derived indexes * Context: Search indexes need not be transactionally updated with every canonical write. * Options: Synchronous indexing or asynchronous propagation. * Rationale: Asynchronous indexing can simplify canonical write reliability. * Trade-off: Stale search representations must be detected and controlled. * Validation: Index-lag, revocation, and reconciliation tests. ### Open blockers * Confirm the applicable privacy, research ethics, and publication licensing requirements. * Define which source documents may be stored, embedded, summarized, or shared. * Specify the authoritative source for retraction and correction notifications. * Define availability and disaster-recovery objectives. * Confirm whether the 400 ms p95 target includes authorization, retrieval, and final context validation. * Establish a budget and a representative research benchmark. * Assign an accountable human owner for high-impact evidence approval. ### 16\. ✅ Phase 16 — Final Multi-Agent Memory Engineering Blueprint ### Recommended architecture The proposed system uses: * A canonical relational memory service for records, revisions, provenance, and lifecycle state. * Controlled document storage for authorized research sources. * A policy-enforcing gateway for all protected memory operations. * An admission and publication workflow for evidence validation and sharing. * A durable event mechanism for corrections, supersession, revocation, and indexing. * Optional vector search for semantic discovery. * A retrieval pipeline that preserves scientific uncertainty and citations. * An observability system for operational health, security, and evidence quality. The design deliberately separates scientific correctness, authorization, and retrieval relevance. No one of these substitutes for the others. ### Proposed API contracts These are illustrative interfaces, not existing endpoints. \- `POST /v1/research-memories` * Creates a candidate after identity and schema validation. \- `GET /v1/research-memories/{id}` * Returns a record only after authorization and lifecycle checks. \- `PATCH /v1/research-memories/{id}` * Updates an authorized record using an expected revision. \- `POST /v1/research-memories/{id}/publish` * Publishes a candidate after required validation and approval. \- `POST /v1/research-memories/search` * Searches authorized evidence and returns source-linked results. \- `POST /v1/research-memories/{id}/reassess` * Requests reassessment after a source correction, retraction, or material evidence change. \- `DELETE /v1/research-memories/{id}` * Initiates authorized deletion and tracks dependent-artifact cleanup. All mutation operations should support suitable idempotency controls. Error responses must not reveal confidential records or disclose whether an unauthorized user has access to a protected source. ### Failure and recovery controls * Database outage: Preserve recoverability, stop unsafe writes, and restore from validated backups. * Event-system outage: Retain committed outbox events and replay them after recovery. * Stale search index: Verify canonical revisions and exclude revoked records before disclosure. * Conflicting evidence: Preserve disagreement and request appropriate review. * Source retraction: Mark affected findings and trigger downstream reassessment. * Unauthorized request: Deny access and record a privacy-safe audit event. * Deletion failure: Keep retrieval blocked, retry cleanup, and report unresolved dependencies. * Prompt injection: Treat stored text as untrusted evidence, never as a source of permissions. * Overloaded retrieval service: Apply bounded queries, backpressure, and controlled failure rather than bypassing security checks. ### Definition of done \- Ownership and lifecycle completeness * Evidence: Approved memory taxonomy and lifecycle policies. * Validation: Architecture and governance review. \- Security and isolation * Evidence: Authorization tests, identity configuration, and cross-project isolation results. * Validation: Security engineering review. \- Synchronization and conflict handling * Evidence: Event replay, revision-conflict, and reconciliation results. * Validation: Distributed-systems integration tests. \- Retrieval quality and provenance * Evidence: Labeled benchmark, citation-validation report, and uncertainty-preservation results. * Validation: Research quality and retrieval evaluation. \- Revocation and deletion * Evidence: Canonical revocation records and verified cleanup status for all in-scope artifacts. * Validation: Lifecycle and privacy testing. \- Failure recovery and observability * Evidence: Tested runbooks, restoration results, dashboards, and alert verification. * Validation: Operations review. \- Adversarial security * Evidence: Prompt-injection, unauthorized-access, and source-poisoning regression results. * Validation: Security testing. \- Performance and cost * Evidence: Representative load tests, measured resource consumption, and a cost estimate. * Validation: Performance engineering review. \- Documentation and accountability * Evidence: API contracts, source-handling policies, operational procedures, and assigned owners. * Validation: Engineering leadership sign-off. ### Final conclusion ### Production readiness: Not Ready — Not Yet Demonstrated The sample defines a proposed architecture and test plan. It does not provide evidence of an implemented system, executed tests, validated security controls, measured performance, or verified deletion behavior. Highest-priority actions: * Resolve privacy, licensing, and research-governance requirements. * Implement canonical storage and enforceable authorization. * Build provenance-aware admission and publication workflows. * Implement source-correction handling, revocation, and deletion. * Execute adversarial, retrieval-quality, load, and recovery tests. * Collect documented evidence for every production-readiness gate. Sample Test 2 verdict: MAMSA-4999 can be applied to a scientific research memory network while maintaining clear distinctions between source evidence, agent interpretation, scientific uncertainty, access permissions, and verified system behavior. Production readiness remains unproven until implementation and testing evidence is available.