MCP Obsidian to Data Orchestrator

Current decision

Build mcp-obsidian first as the smallest complete vertical slice. Do not begin by inventing a general Data Orchestrator disconnected from observed execution.

The first implementation must complete one real data lifecycle:

receive bounded intent and content
→ identify the artifact
→ add required metadata
→ write to the Obsidian vault
→ read the result back
→ calculate and verify its digest
→ record the revision and delta
→ return a machine-readable execution receipt

After this path works reliably, extract the provider-independent behavior into a Data Orchestrator core and retain Obsidian as the first adapter and reference implementation.

Why this sequence

mcp-obsidian gives the project a concrete environment in which paths, Markdown, metadata, revisions, conflicts, readback, and receipts can be observed. Those observations reveal which behavior is truly common and which behavior exists only because Obsidian uses a local vault.

The intended evolution is therefore:

mcp-obsidian vertical slice
→ verified operation contracts
→ common behavior identified from evidence
→ Data Orchestrator core extracted
→ additional provider adapters added

This is extraction and generalization from a working implementation. It is not class inheritance from an Obsidian-specific object model.

Shared object model

The Command Center, mcp-obsidian, the future Data Orchestrator, and the replicated document fabric can use the same logical records:

• stable artifact or document identity;
• project and artifact type;
• revision and lifecycle status;
• content digest;
• provenance and acting identity;
• canonical location when one is declared;
• replica locations and provider account identities;
• delta since the preceding accepted revision;
• verification state and last readback time;
• execution receipt and audit evidence.

The components share these contracts, but they do not have the same responsibility.

Responsibility boundary

Command Center

The Command Center is the human- and agent-readable observability surface. It answers:

• what exists;
• what state it is in;
• where replicas are located;
• which identities acted;
• what changed;
• which evidence supports the displayed state.

It should eventually read normalized metadata from the Data Orchestrator instead of relying on manually maintained snapshots.

MCP Obsidian

mcp-obsidian is the first executable vertical slice. It handles one provider-specific environment and proves the end-to-end write, readback, revision, delta, and receipt path.

Data Orchestrator

The Data Orchestrator will receive a bounded data intent and perform the complete governed lifecycle:

validate intent
→ resolve artifact identity
→ resolve provider accounts and routing policy
→ contact storage or database adapters
→ write the new revision
→ replicate to declared destinations
→ independently read back
→ verify digest and metadata
→ record delta, health, and failures
→ return one execution receipt

Provider services remain convenient replica and access surfaces. They do not decide the identity, authority, routing, or accepted state of the logical artifact.

Multiple accounts and providers

The future orchestrator must support several explicit accounts for the same provider. A route must identify the account by a stable internal alias plus observed provider identity, not by whichever OAuth session happens to be active.

Example:

replicas:
  - adapter: google-drive
    account_alias: google-alpha
    provider_account_id: observed-id
    destination: /PUNNARAJ/OFFICIAL
  - adapter: google-drive
    account_alias: google-admin
    provider_account_id: observed-id
    destination: /BACKUP/OFFICIAL
  - adapter: r2
    account_alias: r2-primary
    destination: official/
  - adapter: github
    account_alias: github-punnaraj-dev
    destination: punnaraj-dev/punnaraj-docs

An AI should be able to request counts, drift, missing replicas, revision metadata, or a bounded report without retrieving the full contents of every provider account.

Intended MCP operation

The long-term interaction should reduce a multi-provider write to one bounded request:

{
  "operation": "publish_artifact",
  "project": "punnaraj-system",
  "artifact_type": "architecture-record",
  "content": "...",
  "replication_policy": "project-default"
}

The orchestrator performs the provider calls, metadata updates, verification, retry, partial-failure preservation, and receipt generation.

Migration of the current workflow

Today, an agent may need to write the same accepted understanding separately to Command Center, Core Principles, and Punnaraj Docs. Once the MCP vertical slice and extracted orchestrator are verified, this manual pattern should become one governed publish operation with three declared destinations.

The repositories remain distinct surfaces:

• command-center: observability and operational presentation;
• core-principles: principle-level public-readable meaning;
• punnaraj-docs: canonical versioned design and audit record.

The Data Orchestrator will coordinate their writes without collapsing their different purposes into one repository.

Minimum implementation phases

1. Obsidian local vertical slice — write, readback, digest, revision, delta, receipt.
2. R2 replica — add one remote provider and preserve partial failures.
3. Identity registry — bind every adapter call to an explicit provider account identity.
4. Replication policy — route one artifact to several declared destinations.
5. Metadata queries — counts, health, drift, missing revisions, and changed-since reports without full-content retrieval.
6. Extract Data Orchestrator core — move provider-independent contracts and lifecycle logic out of the Obsidian adapter.
7. Command Center integration — render orchestrator metadata and evidence as the current operational view.

Current evidence boundary

This document records an accepted architecture direction. It does not claim that mcp-obsidian, the Data Orchestrator, cross-provider replication, or Command Center integration has been implemented or tested.