Track C2 — qualify shared context / agent memory substrate for Yukh #63

Objective

Determine whether Yukh should rely on an external shared context substrate rather than building persistent memory/context machinery.

The original concern was shared/team memory. The qualification now explicitly tests whether that boundary is too narrow. Memory, canonical knowledge projections, resources, skills-as-proposals, code-derived knowledge and context navigation may form a cleaner replaceable substrate together.

Qualification strategy — elimination tree, not product contest

Do not run six products through a feature-score competition.

Test the architecture in this order:

Can OpenViking alone satisfy the complete shared-context profile?
                     |
              +------+------+
              |             |
             YES            NO
              |             |
            STOP       Why did it fail?
                            |
                  +---------+----------+
                  |                    |
             memory profile       context profile
                weak                  weak
                  |                    |
        qualify memory          reconsider broader
        specialists             substrate / simpler
                  |
          Cognee / TencentDB

Graphiti and Mem0 are challengers/baselines used to test specific assumptions, not components that Yukh intends to install by default. ai-memory remains the minimal simplicity baseline.

Allowed final outcomes

1. OpenViking alone — one external context substrate covers canonical projections + derived context + skills/resources + shared memory sufficiently well.
2. OpenViking + memory specialist — OpenViking wins context/navigation/resources but needs Cognee or TencentDB for the shared/team-memory profile.
3. Memory specialist + canonical Git/simple indexing — OpenViking breadth does not justify itself; keep ADR/RFC/Golden Path/docs canonical in Git with simpler projection/indexing and use a focused memory provider.
4. Gap remains — none of the tested boundaries satisfy the invariants cleanly.

Do not add a second component when the first already satisfies the profile.

Candidates

First candidate to execute: volcengine/OpenViking

OpenViking is the primary full context-substrate hypothesis and MUST be qualified first.

Its breadth is not a disadvantage. It is specifically being tested to determine whether Yukh should externalize a larger context plane instead of composing separate memory, knowledge, skills and code-context systems.

Memory specialists if OpenViking needs one

• topoteretes/cognee — primary shared-memory/control-plane challenger.
• TencentCloud/TencentDB-Agent-Memory — primary explicit team-memory candidate.

Only qualify them as complements after identifying a concrete OpenViking memory-profile gap, unless documentary preflight reveals a blocker that prevents executing OpenViking at all.

Specialist challengers / baselines

• getzep/graphiti — temporal/provenance challenger. Use it to test whether temporal fact evolution materially improves stale/conflicting-context semantics.
• mem0ai/mem0 — mainstream memory baseline. Use it to test whether conventional scoped memory is sufficient and broader machinery unnecessary.
• akitaonrails/ai-memory — minimal/reference baseline for Git/Markdown portability and simplicity.
• Hermes embedded memory and OpenHuman integrated memory remain host/platform benchmarks.

Core architectural hypothesis

Yukh should own only the contracts separating context from:

• authority;
• accepted state;
• evidence truth;
• capability authorization;
• coordination ownership;
• Golden Path acceptance/governance.

Storage, retrieval, indexing, graph construction, context navigation, memory distillation, resources and proposed skills should be external replaceable machinery when possible.

Canonical knowledge versus context projection

ADR, RFC, Golden Path, policies and other reviewed artifacts may participate in the context plane, but the context provider is not their source of truth.

Git / reviewed canonical artifacts
          |
          | source of truth
          v
external context substrate
          |
          | indexed / graph / semantic runtime projection
          v
       agents

Examples:

• accepted ADR/RFC/Golden Path source remains the reviewed/versioned canonical artifact;
• OpenViking/Cognee/etc. may ingest, index, relate and retrieve it;
• a derived summary or graph relation is contextual, not canonical;
• a learned Skill is a proposal until separate governance accepts it;
• memory can inform work but cannot override an accepted Yukh fact/evidence record.

The qualification should preserve enough provenance to distinguish at least conceptually:

canonical
  derived
  remembered
  proposed

Provider-native labels need not match these names; Yukh must be able to classify the returned context without granting the provider authority.

Candidate-neutral context seam hypothesis

Start with the smallest useful seam:

search(actor, scope, query)
read(ref)
provenance(ref)
visibility(ref)
freshness(ref)

Richer substrates may expose optional capabilities such as:

navigate(ref, relation)
resources(scope)
proposedSkills(scope)
temporalHistory(ref)

The executable qualification determines whether any optional capability deserves to become part of the stable Yukh context-provider contract.

The provider MUST NOT own operations equivalent to:

grantCapability(...)
acceptProjectState(...)
acceptEvidenceTruth(...)
transferOwnership(...)
approveGoldenPath(...)

First executable qualification — OpenViking

Use one synthetic project/team and two replaceable agent-host identities. No production or personal data.

The fixture should contain:

• one canonical RFC/ADR-like document with stable source revision;
• one Golden-Path-like canonical document;
• one tiny code repository/resource;
• one remembered contextual fact;
• one proposed/learned Skill;
• one stale or conflicting contextual fact;
• one restricted/revocable asset where the OSS profile supports visibility controls.

Gate OV-1 — public substrate seam

Pin an exact OpenViking revision and prove through supported public surfaces only that the fixture can be ingested and retrieved/navigated. No private DB mutation or candidate patching.

Gate OV-2 — host replaceability

Agent host A and agent host B must be able to consume the same contextual assets without changing Yukh participant/work semantics and without host-native memory becoming required.

Gate OV-3 — canonical projection boundary

Retrieve ADR/RFC/Golden-Path-like content and prove the returned context retains a stable provenance/source reference. Mutating or re-summarizing provider state must not silently mutate the canonical Git artifact or turn a derived representation into accepted state.

Gate OV-4 — memory profile

Test remembered context, stale/conflicting context, persistence across host replacement, and candidate outage. A memory claim must not override a separately supplied accepted Yukh fact/evidence record.

Gate OV-5 — visibility / revocation

Use the narrowest supported OSS/self-hosted visibility model. Restricted context must not become visible to the wrong actor. If the OSS profile lacks sufficient team isolation/revocation, record this as a concrete memory-profile limitation rather than compensating inside Yukh.

Gate OV-6 — Skills and broader context

A candidate-generated/learned Skill may be retrieved and used as contextual guidance, but must remain proposed from Yukh's perspective until separately accepted through Golden Path governance.

OpenViking agent/peer/capability concepts must not substitute Yukh MCP capability authority or Yukh Coordination participants/HANDOFF semantics.

Gate OV-7 — outage correctness

Yukh work/authority/accepted-state semantics must remain correct when OpenViking is unavailable. Context may be missing; authority must not be.

Gate OV-8 — adapter and operational cost

Record:

• public APIs/protocols used;
• candidate-specific concepts exposed through the adapter;
• persistence/storage dependencies;
• embedding/inference/model dependencies;
• whether model traffic must traverse OpenViking;
• self-host profile and network requirements;
• license/distribution implications at the pinned revision;
• bootstrap/runtime cost;
• amount of Yukh machinery eliminated if adopted.

OpenViking decision rule

OPENVIKING_ALONE

Use when OpenViking satisfies the shared/team-memory requirements and the broader context profile while preserving all authority boundaries. If this result is reached, stop: do not add Cognee/TencentDB merely for feature completeness.

OPENVIKING_PLUS_MEMORY_SPECIALIST

Use only when OpenViking materially wins the broader context profile but has a specific, evidenced deficiency in shared/team memory (for example ACL, revocation, lifecycle, temporal conflict handling or team isolation) that a focused provider may solve without unacceptable complexity.

Then qualify Cognee and TencentDB specifically against the missing memory dimensions, not against OpenViking's entire feature set.

MEMORY_SPECIALIST_PLUS_CANONICAL_GIT

Use when OpenViking's broader substrate does not eliminate enough machinery or introduces excessive semantic/operational coupling. Keep reviewed ADR/RFC/Golden Path/docs in canonical Git with a simpler projection/indexing path and qualify Cognee/TencentDB for memory only.

GAP_REMAINS

Use when neither broad nor focused external machinery preserves the required boundaries/profile.

Mandatory invariants

• context/memory is not Yukh authority;
• context/memory is not accepted project state;
• context/memory is not evidence truth;
• context/memory is not coordination ownership or HANDOFF;
• capability/peer concepts from a provider do not become Yukh authorization/participants implicitly;
• retrieval cannot silently mutate Yukh state;
• canonical reviewed Git artifacts remain source of truth;
• context substrate is a runtime/indexed projection of canonical artifacts, not their replacement;
• Yukh remains correct when context is unavailable;
• stale/conflicting memory is detectable or safely contextualized;
• restricted visibility/revocation is enforceable in the qualified profile or explicitly fails that profile;
• learned/generated Skills remain proposals until separately governed;
• no chain-of-thought is required or persisted as Yukh evidence;
• no host-native integration makes a candidate mandatory;
• no extra component is adopted when a simpler qualified topology already satisfies the profile.

Memory-specialist follow-up, only if triggered

If OpenViking reaches OPENVIKING_PLUS_MEMORY_SPECIALIST, qualify Cognee and TencentDB against the same missing dimensions using the same synthetic fixture and actor identities.

Compare specifically:

• shared/team ACL and isolation;
• provenance/version/status;
• revocation/deletion;
• stale/conflicting memory behavior;
• cross-host reuse;
• outage behavior;
• model/proxy path;
• self-host dependencies;
• adapter cost.

Graphiti may be introduced if temporal/conflict semantics remain unresolved. Mem0 provides the mainstream conventional-memory baseline. ai-memory provides the minimal/simple baseline.

Deliverables

1. pinned documentary assessment for OpenViking before execution;
2. candidate-neutral context contract and common synthetic fixture;
3. executable OpenViking OV-1…OV-8 qualification where public seams permit it;
4. explicit OpenViking result: OPENVIKING_ALONE, OPENVIKING_PLUS_MEMORY_SPECIALIST, MEMORY_SPECIALIST_PLUS_CANONICAL_GIT, GAP_REMAINS, or QUALIFICATION_GAP;
5. only if triggered, focused Cognee/TencentDB comparison;
6. Graphiti/Mem0/ai-memory benchmark evidence only where it answers an unresolved architectural question;
7. recommendation on the stable Yukh context-provider seam;
8. precise inventory of machinery Yukh can avoid owning;
9. relationship between learned Skills and Golden Path governance;
10. recommendation on whether any Yukh memory/context implementation is needed — default hypothesis remains no new yukh-memory repository.

Guardrails

• OpenViking first;
• elimination tree, not feature contest;
• no new Yukh memory/context repository before qualification;
• no adoption decision from stars, novelty or feature count;
• no artificial restriction to memory if the broader substrate is cleaner;
• no production data, credentials, repositories or personal memory;
• pin external revisions before executable tests;
• public supported seams only for PASS;
• no changes to yukh-mcp, yukh-projects or yukh-coordination merely to accommodate a candidate;
• no RFC change unless qualification proves a material authority/topology change.

Related: #56 landscape review. Track A / #58 is concluded independently.