docs(workplans): add memory profile pilot plan

This commit is contained in:
2026-05-15 00:23:29 +02:00
parent d07f349168
commit a2daf9a46b
2 changed files with 194 additions and 2 deletions

View File

@@ -4,7 +4,7 @@ type: workplan
title: "Infospace Backend Abstraction"
domain: markitect
repo: infospace-bench
status: planned
status: todo
owner: markitect
topic_slug: markitect
created: "2026-05-14"
@@ -154,4 +154,3 @@ state_hub_task_id: "20d75d49-f62a-4236-a895-698cd2fae45a"
`IB-WP-0013` should prove generation parity on the default local backend first.
This workplan then makes the same infospace operations portable across storage
backends.

View File

@@ -0,0 +1,193 @@
---
id: IB-WP-0017
type: workplan
title: "Agentic Memory Profile Infospace Pilot"
domain: markitect
repo: infospace-bench
status: todo
owner: markitect
topic_slug: markitect
created: "2026-05-15"
updated: "2026-05-15"
depends_on_workplans:
- IB-WP-0010
- IB-WP-0014
related_workplans:
- MKTT-WP-0016
- KONT-WP-0017
state_hub_workstream_id: "b549b9fe-0ebe-4fa9-9d60-c317e44032f5"
---
# IB-WP-0017: Agentic Memory Profile Infospace Pilot
## Goal
Validate the agentic memory graph/profile architecture in a concrete
infospace without turning `infospace-bench` into a memory runtime.
`markitect-tool` should own graph/profile contracts and context-package
compilation. `kontextual-engine` should own durable memory state and
permission-aware runtime behavior. `infospace-bench` should own the applied
pilot: corpus selection, project configuration, evaluation metrics, workflow
traces, and practical feedback to lower layers.
## Intent
Use a real infospace workflow to answer practical questions:
- Which reasoning decisions should become durable memory?
- Which conversation or workflow events are useful later?
- Which knowledge graph neighborhoods improve infospace evaluation and review?
- Which context package shapes are helpful for agents?
- Which profile parameters are too abstract, missing, or misplaced?
This workplan should produce evidence and fixtures, not reusable runtime
infrastructure.
## Non-Goals
- Do not implement graph/event persistence in `infospace-bench`.
- Do not redefine Markitect memory graph/profile schemas.
- Do not require live LLM calls in the default test suite.
- Do not store secrets, provider credentials, or durable user memory inside an
infospace.
- Do not make an infospace backend act as a general memory service.
## T01 - Select pilot corpus and memory questions
```task
id: IB-WP-0017-T01
status: todo
priority: high
state_hub_task_id: "a84301cc-b6b8-4f16-8b21-8d5510160ab8"
```
Choose a bounded pilot, likely one of the existing ebook or reference
infospaces, and define the memory questions it should exercise.
The pilot should cover:
- reasoning decisions during generation or review
- conversation/workflow events worth replaying
- stable knowledge facts and relationships
- activation needs for later agent work
- evaluation questions and acceptance thresholds
Output: pilot selection note and memory-question matrix.
## T02 - Create Markitect-compatible memory fixtures
```task
id: IB-WP-0017-T02
status: todo
priority: high
state_hub_task_id: "105f6555-243c-4374-8010-b2a61f6df83e"
```
Create fixture data that uses the `markitect-tool` memory graph/profile
contracts.
Fixtures should include:
- decision graph snippets from infospace planning or review
- conversation/workflow event paths
- knowledge graph neighborhoods over real infospace artifacts
- memory profile examples with budgets, retention intent, and policy metadata
- expected context package outputs
Output: checked-in fixture set and validation docs.
## T03 - Evaluate context package usefulness
```task
id: IB-WP-0017-T03
status: todo
priority: high
state_hub_task_id: "243d478c-b17e-4cd8-9562-edf3072eaf9c"
```
Use Markitect-generated context packages in concrete infospace tasks.
Evaluate:
- whether activated context improves task restart quality
- whether provenance is enough for review
- whether token budgets are realistic
- whether decision paths and knowledge neighborhoods are understandable
- where packages become noisy or incomplete
Output: evaluation report, metrics history, and recommended contract changes.
## T04 - Plan optional engine-backed runtime integration
```task
id: IB-WP-0017-T04
status: todo
priority: medium
state_hub_task_id: "db8ebf8b-4507-48de-a168-6eb82e584687"
```
Design an integration scenario where `kontextual-engine` provides durable
memory graph/event state behind an infospace workflow.
The plan should define:
- what remains file-backed in the pilot
- what would be engine-backed later
- sync and dry-run behavior
- provenance and audit expectations
- review gates for durable memory writes
Output: integration plan aligned with `IB-WP-0010` and `KONT-WP-0017`.
## T05 - Add applied memory workflow traces
```task
id: IB-WP-0017-T05
status: todo
priority: medium
state_hub_task_id: "4f8dccbc-329f-484e-97ad-1d6d049d3001"
```
Capture applied workflow traces that show how memory records arise from real
infospace work.
Examples:
- generation plan decisions
- entity/relation review decisions
- evaluation failures and fixes
- source chunk triage
- agent handoff or restart context
Output: trace examples and review notes.
## T06 - Feed architecture findings back to lower layers
```task
id: IB-WP-0017-T06
status: todo
priority: medium
state_hub_task_id: "c4b08c44-9c80-4b58-a050-1362996bae4d"
```
Summarize what the pilot proves or falsifies.
The feedback should identify:
- Markitect contract gaps
- engine runtime needs
- profile parameters that are too vague or too detailed
- useful default package shapes
- application-specific behavior that should stay in `infospace-bench`
Output: architecture feedback note and proposed follow-on workplans where
needed.
## Acceptance
- The pilot validates memory profiles against a concrete infospace workflow.
- All reusable contract feedback is routed to `markitect-tool`.
- Durable runtime needs are routed to `kontextual-engine`.
- `infospace-bench` remains the application/evaluation layer.
- Default tests and fixtures stay deterministic and credential-free.