Backend: `fortemi` (alpha, legacy for search)

Backend: `fortemi` (alpha, legacy for search)

Routes a subsystem's persistence into Fortemi, the first-party AIWG semantic-memory project. Fortemi is Rust + PostgreSQL + pgvector with SKOS hierarchies, MRL embeddings, and W3C PROV provenance. Communication happens over MCP.

Status: alpha MCP storage adapter

The adapter ships with the parameter shapes documented in `phase-4-fortemi-review.md`, but those shapes have not been formally validated against a live Fortemi instance. Real-world parameter mismatches surface as MCP errors that bubble up to the consumer.

This adapter is deprecated for index/search routing. New discovery, artifact query, graph traversal, and release-package fallback work uses the Fortemi Core static-cache backend by default; `--backend local` selects the legacy local fallback during the phase-out window.

Use this backend when:

  • You're running AIWG against a Fortemi instance and want memory artifacts to flow into Fortemi's semantic-memory graph
  • You're prototyping the integration

Fortemi Core Migration Boundary

This backend is the older Fortemi MCP storage adapter. It is not the Fortemi Core index/search backend used by:

aiwg index sync
aiwg index query "..."
aiwg index neighbors --graph kb

Configuring a subsystem with `"type": "fortemi"` changes persistence for that subsystem through Fortemi MCP tools. It does not switch AIWG discovery, artifact query, graph traversal, research-query, or KB traversal to the Fortemi Core static cache. Those paths use Fortemi Core by default after an artifact graph sync; `--backend local` selects the legacy local fallback during the phase-out window.

Release packages also include a prebuilt Fortemi Core `framework` index for capability discovery fallback. See `docs/fortemi-core-prebuilt-indices.md` for the cache contract and release matrix maintenance workflow.

There is also a separate, explicit conversion command:

aiwg index export --format fortemi-shard --graph project --out aiwg-project.shard

That command maps an AIWG v2 static index through the installed `@fortemi/core/aiwg-index` converter. It does not use this MCP adapter. Conversely, a successful `aiwg storage test` does not prove that a generated shard is accepted by a Fortemi server. Shard compatibility must name a profile and pass the published-package, server-owned-schema, and real server import/re-export gates documented in `docs/integrations/fortemi-index-export.md`.

Configuration

{
  "version": "1",
  "backends": {
    "memory": {
      "type": "fortemi",
      "mcpServer": "fortemi",        // optional, default: "fortemi"
      "scheme": "aiwg-memory"        // optional SKOS scheme to scope writes
    }
  }
}
FieldRequiredNotes
`mcpServer`noMCP server name registered via `aiwg mcp add`. Default `"fortemi"`
`scheme`noOptional SKOS scheme (vocabulary scope) for this subsystem's notes

No env vars in `storage.config`. Authentication is governed by the AIWG MCP server config — register the Fortemi server via `aiwg mcp add fortemi --command <…>` first.

How it works

The adapter routes the storage interface to Fortemi MCP tools:

AIWG opFortemi tool
`read``get_note`
`write` (new)`capture_knowledge`
`write` (existing)`update_note` (versions are first-class)
`list``list_notes` (filtered by `id_prefix`)
`delete``update_note { archived: true }` (Fortemi is immutable)
`query``search`

Note-id namespacing

Each entry stored in Fortemi has `note_id = subsystem + ':' + path`. The subsystem prefix prevents collisions across `kb`/`memory`/`research`/etc. when they share a single Fortemi instance.

Example: `aiwg memory put research-complete/index.md` → Fortemi note_id `memory:research-complete/index.md`.

Delete semantics

Fortemi's design is immutable — no destructive delete. The adapter's `delete()` issues `update_note { archived: true }` instead, which suppresses the note from `list`/`read` but preserves history. If you need a "real" delete, do it through Fortemi's admin tooling.

Capabilities

OperationNotes
`read`Returns `null` for `not_found`; prefers `revised_content`
`write`Calls `capture_knowledge` for new IDs, `update_note` for existing
`list`Filters by subsystem prefix; strips prefix from returned paths
`delete`Archives via `update_note`; no-op for missing
`query`Implemented (Fortemi has native semantic search)

Caveats

  • Alpha stability. Parameter shapes are based on the planning doc, not a live API. File issues if you see schema mismatches.
  • Async model. Fortemi's NLP pipeline runs server-side; `write` returns when the tool call is accepted, not when the artifact is queryable.
  • Stdio transport only in v1. HTTP/SSE MCP transports are out of scope; the default factory throws clearly if config requests them.
  • No `update`-on-conflict semantics. Two concurrent `write`s to the same `note_id` may race at the Fortemi side. Behavior is governed by Fortemi's versioning model, not by the adapter.

Setup

1. Install and run Fortemi (separately from AIWG). 2. Register the Fortemi MCP server with AIWG:

   aiwg mcp add fortemi --type stdio --command <fortemi-mcp-binary>

3. Add the backend to `.aiwg/storage.config`:

   {
     "version": "1",
     "backends": {
       "memory": { "type": "fortemi", "mcpServer": "fortemi", "scheme": "aiwg-memory" }
     }
   }

4. Verify:

   aiwg doctor
   aiwg storage test memory

5. (Optional) Migrate existing AIWG memory:

   aiwg storage migrate memory --from fs:.aiwg/memory --to fortemi:fortemi

See also

  • `.aiwg/planning/training-framework/phase-4-fortemi-review.md` — Fortemi architecture review
  • `docs/storage/migration.md` — bulk migration into Fortemi
  • AIWG MCP server registry: `aiwg mcp list`, `aiwg mcp add`