Skip to content

Chen Architectural Intent

Chen exists because AncientOS v3 moved from component-centric capability cataloging toward workflow-centric applications.

Chen is not a media manager. Chen is not kernel logic. Chen is the application/workflow orchestration layer that lets AncientOS coordinate operator-facing workflows without moving domain logic into the governed kernel.

The governing rule remains:

Kernel governs -> Chen orchestrates -> Domains implement

The kernel owns governance, routing, policy, approval boundaries, audit, replay, capability visibility, and records. Chen owns workflow orchestration: turning operator intent into domain plans, candidate choices, approval packets, and execution requests. Domains implement subject-specific logic behind Chen.

Why Media Came First

Media became Chen's first active domain because it exercises the whole application path while producing real operator value.

Media is not just a status page. It requires intent resolution, existing-state inspection, provider discovery, candidate planning, approval, execution, and future verification. It touches external adapters such as Plex, Bitmagnet, qBittorrent, Gluetun, and future acquisition sources while preserving strict governance.

That makes Media a useful reference domain:

  • It has a clear end-to-end workflow.
  • It solves an operator-recognizable problem.
  • It exercises read-only planning before mutation.
  • It exercises Lich approval.
  • It exercises fail-closed execution.
  • It exercises replaceable external adapters.

Evolution

The first rough shape was:

Chen -> Bitmagnet

That was too narrow. It made a provider look like the workflow, and it made Chen appear to know where media comes from.

The current shape is:

Chen
-> Media Resolver
-> Acquisition Broker
-> Acquisition Agents
-> Approval
-> Execution

This abstraction is superior because it separates workflow intent from provider implementation. Chen does not need to know whether a candidate came from Bitmagnet, an open-media fixture, a future Usenet provider, an HTTP source, a commercial API, or an institutional repository. Chen asks the domain resolver what the operator wants, asks the broker who can satisfy it, reasons over candidates, and then prepares an approval packet if there is a safe next step.

Acquisition Broker Intent

Chen should never know where media comes from.

Chen asks:

Who can satisfy this request?

The Acquisition Broker asks acquisition agents. Agents produce candidates with evidence, confidence, source type, legality notes where known, warnings, and blockers. Chen reasons over those candidates instead of binding itself to a specific source.

The broker remains read-only. It does not approve, dispatch, import, refresh Plex, or mutate state.

Intent-First UX

Chen is an operating experience, not a collection of exposed tools.

The operator speaks in goals. Chen speaks in outcomes. Provider names, URLs, magnet links, adapter names, API targets, and agent internals are implementation details and should stay hidden in default responses.

The default conversation order is:

Intent -> Decision -> Outcome -> Details on request

not:

Intent -> Implementation -> Outcome

For Media, this means a request such as "Luna, I'd like to watch Big Buck Bunny" should say whether the title is already available, whether a candidate was found, what approval is required, and whether any action was taken. It should not default to exposing the provider, URL, magnet link, broker internals, or qBittorrent API target.

Progressive disclosure remains available for operator trust and debugging:

  • "Why?" may explain the decision path.
  • "Show evidence" may show broker and provider reasoning.
  • "What source?" may reveal provider/source details.

This keeps normal use outcome-oriented while preserving inspectability when the operator asks for it.

Agent Philosophy

Acquisition agents are replaceable provider adapters.

Current agents include:

  • Bitmagnet metadata provider.
  • Legal demo/open-media provider for known safe validation fixtures such as Big Buck Bunny.

Future agents may include:

  • Usenet.
  • HTTP sources.
  • Commercial APIs.
  • Institutional repositories.
  • Internal archives.
  • Other governed acquisition providers.

Chen should remain unchanged when providers are added, removed, degraded, or replaced. Provider-specific logic belongs in agents and adapters, not in Chen's workflow orchestration.

Approval Philosophy

Planning is always allowed when it is read-only.

Mutation is never implicit.

Approval packets exist to separate reasoning from execution. A packet captures the proposed action, candidate evidence, destination, expected mutation, risk, and audit placeholders before anything mutates. Lich approval is explicit, scoped, and reviewable. Missing, expired, unclear, or tampered approval fails closed.

Execution is only a bounded response to approval. For the current Media domain, the only implemented mutation is submitting one paused qBittorrent job. That is dispatch completion, not download completion, import completion, Plex refresh, or playback.

First Complete User Story

The reference user story is:

User: Luna, I'd like to watch Interstellar.

Chen should:

  • Resolve the operator's intent.
  • Check Plex through a read-only adapter.
  • Query the Acquisition Broker if Plex is missing the title.
  • Rank provider candidates.
  • Prepare an approval packet from the selected candidate.
  • Wait.

After explicit approval, Chen may dispatch the approved paused qBittorrent job.

Future slices may add governed import, Plex refresh, and playback offer steps. Those future mutations still need their own approval and evidence boundaries.

This is the first governed application workflow because it crosses the full path from natural-language operator intent through planning, provider selection, approval, and bounded execution while preserving the kernel's authority boundaries.

Cross-Domain Future

Media is expected to become the reference Chen domain.

Future domains should likely follow the same pattern:

Resolver -> Broker -> Agents -> Approval -> Execution

Examples:

  • Home: resolve an intent, broker capable devices/services, choose an action, require approval for mutation, execute through a bounded adapter.
  • Infrastructure: resolve maintenance intent, broker host/service evidence, choose a remediation candidate, require approval, execute through a governed lane.
  • Knowledge: resolve information intent, broker repositories or indexes, synthesize candidates, require approval before durable memory promotion.
  • Finance: resolve analysis intent, broker data providers, produce candidate actions, require approval before transactions.
  • Publishing: resolve publication intent, broker platforms or drafts, require approval before posting.

Design Rules

  • Chen never owns governance.
  • Kernel never owns domain logic.
  • Domains implement subject logic behind Chen.
  • Chen speaks in outcomes before implementation detail.
  • Default responses hide provider, adapter, URL, and API internals.
  • Details are progressively disclosed only when requested.
  • Adapters are replaceable.
  • Agents are discoverable provider surfaces.
  • Brokers aggregate agents and rank candidates.
  • Reasoning precedes execution.
  • Planning remains read-only.
  • Execution is approval-gated.
  • Approval packets separate thought from action.
  • Operator intent precedes implementation detail.
  • External providers never become authority by being reachable.
  • Transport surfaces render workflows; they do not own workflows.