Interoperability Protocol Layer

Era 6A prepares AncientOS for external interoperability protocols without making those protocols authority sources. Era 6A.5 adds a Rubick MCP Export Bridge that can produce governed, descriptor-only MCP tool catalog data from registered AncientOS capabilities. Era 6A.6 adds a read-only local discovery server. Eras 6A.7 through 6A.9 add authorization, approval packet generation, and governed execution planning without execution. Era 6B adds an explicitly enabled governed read-only execution lane for narrow allowlisted capabilities and keeps the default MCP server behavior as refusal. Era 6E.1 adds a transport-neutral governed enablement path for proposing MCP capability enablement without letting any transport mutate MCP state directly. Era 6E.2 adds transport-neutral capability lifecycle governance and dormant-capability review recommendations without automatic state changes. Era 6E.3 adds capability portfolio governance reports over Rubick export data and lifecycle models without provider invocation, transport dependency, or lifecycle mutation. Era 6F.1 adds a metadata-only skill registry above capabilities. Skills represent durable governed purposes, such as host awareness or MCP governance, and map to capabilities and providers without becoming execution authority. Era 6F.2 adds advisory-only skill intelligence over that registry. It can score skill health and fitness, find gaps and overlaps, label strategic importance, and produce review recommendations without execution, provider invocation, lifecycle mutation, Rubick mutation, Discord dependency, or MCP transport dependency. Era 6F.3 adds a local skill validation harness for deterministic skill reasoning scenarios. Era 6G.1 adds MCP client-shaped compatibility validation for discovery and refusal/success transcripts without requiring live external clients. Era 7A adds transport-neutral conversational governance intake that turns natural-language operator requests into structured governed proposals without LLM calls, execution, provider invocation, approval, or mutation. Era 7B adds objective governance metadata above skills so durable outcomes can be represented, validated, reported, and reasoned about without execution, provider invocation, lifecycle mutation, autonomous goals, automatic planning, or automatic objective promotion and retirement. Era 7C adds advisory gap intelligence and roadmap intelligence for the Objective -> Skill -> Capability -> Provider hierarchy. It reports missing, weak, dormant, unresolved, and underrepresented support and produces recommendations and priority assessments only. It does not execute, invoke providers, create objectives, create skills, create capabilities, mutate lifecycles, mutate roadmaps, or autonomously plan.

Authority Boundaries

Rubick remains the source of truth for capabilities, providers, readiness, and registration state. MCP export is only a mapping layer from Rubick-owned capability records into protocol-shaped descriptors. MCP descriptors do not execute tools, select providers, approve work, mutate memory, or influence routing.

The objective and skill registries are also not authority. The hierarchy is:

Objective -> Skill -> Capability -> Provider -> Execution

A governed objective describes durable purpose and desired outcome. It may map to many skills and direct capability bindings, including unresolved bindings. Objective records never create goals, start plans, invoke providers, mutate lifecycles, apply MCP enablement, or change Rubick capability truth.

A skill may describe intent, governance requirements, evidence requirements, validation requirements, dependency relationships, and unresolved future capability bindings. Rubick remains capability authority, providers remain implementation metadata until governed execution lanes allow them, and skill records never invoke providers or mutate lifecycle state.

MCP is interoperability, not authority. External protocol inputs are untrusted by default. Lich remains approval authority. Zeus remains evidence authority. Every governance projection in this layer is deterministic, fail-closed, and read-only. Era 6B/6D execution is unavailable unless mcp_read_only_execution_enabled is set to true and every governance gate passes. Mutating execution and UCP/commerce execution remain unavailable. No transport may bypass Rubick. Discord, CLI, web, mobile, local tests, and future transports can only submit transport-neutral enablement requests. They cannot directly enable tools, register providers, mutate the governed MCP allowlist, or substitute transport approval for Rubick/Lich/Zeus governance.

Era 6A.5 Rubick MCP Export Bridge

The export bridge maps Rubick capability records and provider relationships into MCP-compatible tool descriptors with AncientOS governance annotations. The bridge is pure and read-only: it performs no network calls, opens no transport, starts no MCP server, registers no external server, and invokes no capability.

Export is descriptor-only because MCP tools are invocable by model clients in the public protocol. AncientOS therefore treats descriptor generation as a high-trust boundary while still refusing to create execution authority. execution_allowed remains false for every decision and descriptor in this phase, including explicitly exported mutating or commerce-related descriptors. network_allowed also remains false because Era 6A.5 does not introduce STDIO, HTTP, sockets, outbound provider calls, or live MCP transport.

Governance metadata is represented under an AncientOS namespaced annotation object. Rubick annotations identify the source capability and provider and state that Rubick remains the source of truth. Lich annotations record that classification and approval are required before any future execution path and that metadata is not authorization. Zeus annotations record evidence requirements and supervision expectations for future replay and audit. These annotations are operator visibility and future server input only; they are not routing or execution permission.

The read-only catalog summarizes inspected capabilities, exported tools, skipped capabilities, skip reasons, represented providers, risk levels, approval-required counts, execution/network counts, commerce status, and fail-closed decisions. Catalog reports are for humans and future server design; they must not be used as a runtime dispatch table.

Inbound MCP providers are disabled by default and untrusted by default. A provider represented through MCP is only a candidate until Rubick registration exists and Lich classifies the requested operation. MCP requests must never route directly to execution.

Era 6A.7-6A.9 Governed MCP Pipeline

AncientOS can now answer governance questions about a future MCP tool request without performing the request:

Discovery
  -> Authorization
  -> Approval Packet
  -> Execution Plan
  -> STOP

Authorization consumes Rubick capability metadata, provider registration, governance annotations, and risk classifications. Unknown capabilities, unknown providers, missing metadata, missing evidence, forbidden capabilities, unknown state, commerce authority, and non-exportable records fail closed. Authorization decisions always report authorized = false and execution_allowed = false in this era. The normal non-error stop reason is discovery_only_phase.

Approval packet generation consumes authorization decisions and emits immutable future-Lich packets. Packet data includes request identity, capability and provider IDs, requester, risk level, required authority, required evidence, governance annotations, replay boundary, execution-disabled status, and approval state. Packets serialize deterministically and reject unknown approval states during validation.

Execution planning consumes authorization decisions and approval packets. It produces a future-phase plan only:

1. Verify Rubick registration.
2. Verify provider registration.
3. Verify approval packet.
4. Verify evidence requirements.
5. Verify replay boundary.
6. Invoke capability (future phase).

The final step is a placeholder boundary, not an invocation path. execution_performed, execution_allowed, provider_invoked, and rubick_invoked remain false for all plans.

Authorization Lifecycle

MCP client request
  -> normalize tool/provider/requester
  -> verify Rubick capability registration
  -> verify provider registration
  -> derive risk and required authority
  -> derive Zeus evidence requirements
  -> return fail-closed authorization report

Approval Packet Lifecycle

Authorization decision
  -> deterministic packet ID
  -> immutable approval packet
  -> deterministic serialization
  -> validation for future Lich integration

Execution Planning Lifecycle

Authorization decision + approval packet
  -> verification plan
  -> explicit replay and evidence gates
  -> future invocation placeholder
  -> stop before execution

UCP is model-only in Era 6A. Merchant, offer, cart, checkout-session, payment intent, order, return, and commerce-intent structures represent possible future commerce state, but they do not create checkout, payment, purchase, refund, cancellation, fulfillment, or merchant mutation authority.

Governance Requirements

Any future mutating action through MCP or UCP requires Lich approval classification before execution. Commerce-related UCP intents require human approval before any transaction can be attempted in a future era. A payment intent is not approval. A checkout session is not permission to purchase.

Zeus evidence artifacts are required before any future governed execution path can consume protocol metadata. Evidence must preserve deterministic replay boundaries, requested scope, provider identity, approval classification, operator decision, validation result, and failure handling.

Era 6E.1 Transport-Neutral Governed MCP Enablement

Era 6E.1 introduces app/interoperability/mcp_enablement/ and the transport-neutral entrypoint prepare_mcp_enablement_request(...).

The path is capability enablement, not tool execution:

Text or object request
  -> parse capability_id and requester metadata
  -> verify Rubick capability record
  -> verify Rubick provider registration
  -> classify read-only, mutating, commerce, or network authority
  -> include validation-harness simulation result when supplied
  -> generate Rubick/Lich/Zeus approval packet
  -> produce enablement plan
  -> STOP unless approved explicit apply is requested
  -> narrow governed allowlist update only
  -> receipt

Default behavior is fail-closed and non-mutating:

• dry_run = true
• apply = false
• approval_state = pending
• enablement_performed = false

Proposal and enablement are distinct. Unknown capabilities produce a proposal-only refusal so an operator can see what was requested, but no provider execution or registry mutation is created. Known capabilities can produce an enablement proposal only when Rubick has a registered provider and the capability is classified as read-only, non-commerce, and non-network. Mutating, commerce, network, missing-provider, unknown-provider, and failed simulation states fail closed.

Apply is allowed only when Rubick already knows the capability, Rubick already has an implemented wired provider, the capability is read-only and provider-backed, the approval packet state is approved, the request explicitly sets apply = true, and dry-run is explicitly disabled with dry_run = false.

The only apply behavior in this phase is a narrow governed MCP allowlist or registry-surface update supplied to the entrypoint. It does not invoke MCP tools, call providers, run shell commands, perform network access, execute commerce, create arbitrary execution paths, or wire Discord command behavior.

Rubick owns capability and provider truth. Lich owns approval and classification authority. Zeus owns evidence and validation expectations. The enablement receipt records requester, session, trust tier, approval state, apply flags, whether registry-surface mutation occurred, and explicit execution_performed = false, mutation_performed = false, commerce_performed = false, and network_performed = false fields.

Discord wiring is intentionally deferred. Future Discord integration must use the same transport-neutral entrypoint and must not add direct Discord mutation or transport-owned governance.

Era 6E.2 Capability Lifecycle Governance

Era 6E.2 introduces app/interoperability/mcp_lifecycle/ for pure, transport-neutral MCP capability lifecycle governance. It models lifecycle records, observations, human reviews, promotion/deprecation/retirement proposals, dormancy reviews, deterministic reports, and receipts.

The governed lifecycle is explicit:

proposed
  -> simulated
  -> approved
  -> enabled
  -> observed
  -> reviewed
  -> promoted
  -> deprecated
  -> disabled
  -> retired
  -> archived

The suspension path is explicit and reversible only by approved transition:

enabled -> suspended -> enabled
suspended -> disabled

Every lifecycle transition must name the action, requester identity, trust classification, authority scope, approval packet, evidence references, and target state. Unknown requesters, unknown actions, missing approval, and invalid transitions fail closed. Simulations answer what would happen if a capability were suspended, promoted, deprecated, retired, or reviewed for dormancy, but they do not mutate lifecycle state.

Dormancy review is recommendation-only. Lifecycle observation records track last successful execution time, execution counts, approvals, refusals, simulations, validation counts, review timestamps, trust concerns, evidence concerns, and review notes. No live telemetry collection is introduced.

Default dormancy policy:

• 0-59 days unused: active
• 60-89 days unused: nearing_dormant
• 90-179 days unused: dormant_review_recommended
• 180+ days unused: stale_review_required
• never-used enabled capability: never_used_review_recommended

At 90 days since last successful execution, AncientOS recommends human review; it does not disable the capability. Dormancy recommendations may suggest keep_enabled, suspend, deprecate, disable, or retire for operator review, but human_review_required is always true and auto_disable_allowed is always false. Any actual suspend, disable, retire, or archive transition still requires an explicit human-approved lifecycle transition.

Retirement uses archive-not-delete governance. Archived lifecycle records keep receipts, attribution, trust metadata, evidence references, and lifecycle history so capability governance remains replayable after operational use ends.

Era 6E.3 Capability Portfolio Governance

Era 6E.3 introduces app/interoperability/mcp_portfolio/ for model-only, transport-neutral MCP capability portfolio governance. It consumes Rubick capability/export catalog data, MCP lifecycle records, lifecycle observations, dormancy recommendations, and approval or evidence metadata where available. It does not require live telemetry.

Portfolio governance answers portfolio-level questions:

• how many MCP capabilities exist
• how many are enabled, disabled, dormant, retired, or unreviewed
• which capabilities need review
• which capabilities are high risk
• which capabilities have missing evidence or stale approvals
• which capabilities are promotion, suspension, deprecation, disablement, or retirement candidates
• which capabilities appear redundant or overlapping

Reports are advisory only. Portfolio recommendations never enable, suspend, disable, deprecate, retire, archive, invoke, or mutate any capability. Human approval remains required for every lifecycle state change. The 90-day unused rule produces review_required, not automatic disablement. The 180-day unused rule produces stale_review_required and still requires human review.

Portfolio health classifies each capability as healthy, needs_review, dormant, stale, missing_evidence, high_risk, disabled, retired, or unknown. Portfolio risk classifies capabilities as low, moderate, elevated, high, or blocked using model-only factors such as mutating authority, commerce authority, external provider metadata, missing evidence, stale approval, repeated refusals, failed executions, dormant-but-enabled state, and unknown lifecycle state.

Dormancy reports aggregate active, nearing dormant, dormant review recommended, stale review required, and never-used review recommended counts. Review backlog reports list dormant capabilities, stale capabilities, missing evidence, high-risk enabled capabilities, unreviewed enabled capabilities, repeated failures, and repeated refusals.

Redundancy detection is model-only and advisory. It compares same provider, same capability category, overlapping description keywords, same lifecycle purpose, and same MCP tool annotation category. Redundancy findings create review recommendations only; they never auto-retire overlapping capabilities.

Rubick remains capability and provider truth. Lifecycle governance remains the only lifecycle state model. Portfolio governance is a visibility layer over Rubick and lifecycle data: it summarizes health, risk, dormancy, review backlog, redundancy, and recommendations for operators without adding new capabilities, execution paths, provider calls, Discord dependencies, or MCP transport dependencies.

Era 6F.1 Skill Registry And Skill-Capability Mapping

Era 6F.1 introduces app/interoperability/skill_registry/ for first-class governed skill metadata. A skill is a durable ability or purpose above capabilities. A capability is still the Rubick-owned implementation unit, and a provider is still implementation metadata beneath the capability.

Seed skills are model-only:

• host_awareness
• mcp_governance
• capability_lifecycle_governance
• capability_portfolio_governance
• capability_enablement_governance

Seed skill capability lists may include future or currently unavailable capabilities. Missing capabilities and providers are represented as unresolved bindings so operators can see intended graph shape without pretending the implementation exists.

Skill contracts record typed preconditions, outputs, allowed actions, validation signals, failure modes, evidence requirements, and governance requirements. Skill graph reports expose skills, capabilities, providers, dependencies, and unresolved bindings. Validation reports warnings and errors for duplicate skill ids, duplicate bindings, missing references, circular dependencies, missing evidence or governance requirements, disabled skills with implemented capabilities, and enabled skills with no implemented capabilities.

Recommendations are advisory only. They may suggest review_skill, add_capability_to_skill, resolve_missing_binding, review_dependency, document_failure_modes, add_validation_signal, or consider_deprecation, but they never modify a registry, lifecycle record, Rubick capability record, provider binding, transport, or execution lane.

The design borrows two ideas from external skill-system research without adopting automatic maintenance. From SkillOpt, AncientOS adopts reusable skill artifacts with evidence and validation gates, but no automatic optimization, rollout, or exported best-skill replacement. From SkillOps-like maintenance, AncientOS adopts typed contracts and a skill ecosystem graph, but no autonomous library maintenance, auto-promotion, auto-retirement, or automatic repair.

Era 6F.2 Skill Intelligence

Era 6F.2 introduces app/interoperability/skill_intelligence/ for model-only analysis of the skill ecosystem. It consumes skill registry data, skill graph data, validation results, and optional capability portfolio items or reports. It does not require live telemetry and does not execute capabilities.

Skill health uses deterministic classifications: healthy, needs_review, weak, dormant, missing_capabilities, overlapping, high_risk, and unknown. Skill fitness is a 0-100 advisory score with bands: 80-100 strong, 60-79 adequate, 40-59 weak, and 0-39 poor. The score considers implemented capability count, unresolved binding count, optional portfolio health, dormancy, evidence completeness, review backlog, failure/refusal signals where supplied, risk level, and validation warnings.

Overlap detection is advisory. It compares shared capabilities, shared providers, shared domain, shared tags, and overlapping purpose or description keywords. A reduce-overlap recommendation asks for boundary review only; it never deprecates or merges skills automatically.

Gap analysis identifies missing implemented capabilities, only-unresolved bindings, missing providers, high strategic importance with low fitness, contract outputs without validation signals, failure modes without mitigation notes, and enabled skills without executable capabilities.

Strategic labels are foundational, operational, governance, integration, experimental, and deprecated. Seed labels mark host_awareness operational, mcp_governance foundational, and capability enablement, lifecycle, and portfolio governance as governance.

Reports include a human-readable skill intelligence report, deterministic JSON snapshot, health summary, fitness ranking, gap report, overlap report, and recommendation report. Recommendations are advisory-only candidates: keep_skill, review_skill, improve_skill, add_capability, resolve_binding, add_validation_signal, reduce_overlap, consider_deprecation, promote_skill, and monitor_skill. They add no new MCP capability, no provider call, no Rubick mutation, no lifecycle mutation, no automatic optimization, no automatic promotion, no automatic deprecation, and no transport or Discord dependency.

Era 6A Non-Goals

• No MCP execution server runtime.
• No MCP client runtime.
• No external MCP server connection.
• No network calls.
• No STDIO or HTTP transport.
• No MCP tool invocation.
• No commerce checkout.
• No payment handling.
• No purchasing execution.
• No Discord command behavior changes.
• No protocol-to-execution routing.
• No advisory metadata authority over routing, memory, approval, or execution.

Era 6A is therefore a descriptor, discovery, authorization, approval-packet, and planning layer: static descriptors, disabled provider stubs, inert commerce models, governance classification helpers, read-only export reports, read-only discovery, immutable approval packets, and non-executing plans only.

Era 6B Governed MCP Read-Only Execution Lane

Era 6B moves one bounded path from planning stop to governed read-only execution:

Discovery
  -> Authorization
  -> Approval Packet
  -> Execution Plan
  -> Invocation Candidate
  -> Lich Approval Gate
  -> Zeus Evidence Gate
  -> Read-Only Executor Facade
  -> Evidence Receipt

The server-level setting is mcp_read_only_execution_enabled. It defaults to false. When false, tools/call returns the same discovery-only refusal as Era 6A. When true, default behavior is still refusal unless the request names an allowlisted read-only tool and supplies matching authorization, approval, planning, and Zeus evidence artifacts.

The executable candidate is limited to:

• inspect_disk_space

That name is only executable through the narrow read-only facade after Rubick capability registration, Rubick provider registration, authorization, approval packet validation, execution plan validation, Lich approval gate, Zeus evidence gate, executor policy, provider adapter allowlist, and receipt generation all pass. The MCP server does not directly call arbitrary Rubick execution, shell commands, Docker, Git, Keeper, LifeVault, Naga, UCP, Discord routing, or network providers.

Era 6D.1 First Real Governed MCP Read-Only Capability

Era 6D.1 wires exactly one real provider-backed read-only capability through the governed MCP lane: inspect_disk_space.

The provider binding is exact:

• MCP tool: inspect_disk_space
• Rubick capability: inspect_disk_space
• Rubick provider: provider_beastmaster_inspect_disk_space
• Beastmaster probe: registered disk_overview

The adapter ignores MCP command/path arguments and invokes only Beastmaster's registered read-only disk overview probe. It accepts no shell strings from MCP arguments, constructs no external command from user input, performs no filesystem writes, makes no network calls, and exposes no Docker, Git, Keeper, LifeVault, Naga, Discord routing, commerce, mutation, or arbitrary execution path.

Real execution remains default-disabled. When enabled, tools/call still fails closed unless all governance context is present: requester identity, session context, execution-eligible trust, read_only_inspection intent, execute_read_only authority, Rubick capability registration, Rubick provider registration, authorization decision, approved approval packet, execution plan, Lich gate, Zeus evidence gate, read-only executor policy, and provider adapter allowlist.

Receipts include requester/session/trust/intent attribution, tool and provider identity, execution status, mutation and network flags, provider invocation status, result summary, sanitized disk-space result, evidence ids, replay boundary, and refusal reason when refused. Receipts must not contain secrets, tokens, credentials, raw environment dumps, or host data beyond the intended sanitized disk-space result.

Era 6D.2 Operator Validation Harness

Era 6D.2 adds a local operator/developer validation harness for inspecting the governed MCP packet chain. The package is app/interoperability/mcp_validation_harness/ and is runnable without a live server, network calls, Discord dependencies, public HTTP transport, arbitrary shell execution, commerce execution, mutating execution, or new capabilities.

The harness simulates request scenarios for the existing governed MCP capability only:

• MCP tool: inspect_disk_space
• Rubick capability: inspect_disk_space
• Rubick provider: provider_beastmaster_inspect_disk_space
• Beastmaster probe: registered disk_overview

Default scenario execution is safe and fake-provider only. The fake provider returns deterministic sanitized read-only evidence so operators can inspect the chain without touching the real host provider. The real-provider scenario is available only when explicitly requested with --allow-real-provider; without that flag it returns a structured refusal.

Operators can inspect the chain with:

python -m app.interoperability.mcp_validation_harness.cli --list-scenarios
python -m app.interoperability.mcp_validation_harness.cli --scenario inspect_disk_space_default_disabled_refusal
python -m app.interoperability.mcp_validation_harness.cli --scenario inspect_disk_space_success_path_with_fake_provider --json
python -m app.interoperability.mcp_validation_harness.cli --scenario inspect_disk_space_success_path_with_real_provider --allow-real-provider

Reports include discovery output, requester identity, session context, intent, trust, authority scopes, authorization decision, approval packet, execution plan, invocation candidate, Lich gate result, Zeus evidence result, execution result or structured refusal, receipt summary, mutation/network/provider flags, and sanitized result data. Reports redact obvious secret-bearing terms and do not include raw environment dumps, tokens, credentials, or secrets.

The harness is validation and inspection only. It does not weaken default-disabled MCP execution, bypass the governed MCP lane, change Discord routing, add public transport, add filesystem writes by default, or register a second MCP capability.

Era 6F.3 Skill Intelligence Validation Harness

app/interoperability/skill_validation_harness/ validates the advisory skill reasoning layer through deterministic local scenarios. It composes the skill registry and skill intelligence modules, then renders human-readable summaries or deterministic JSON. It does not execute providers, mutate lifecycle state, mutate capabilities, optimize skills, promote skills, deprecate skills, retire skills, use Discord, or require MCP transport.

Reports include skill_id, health, fitness_score, fitness_band, strategic_importance, implemented_capability_count, unresolved_binding_count, overlap findings, gap findings, recommendations, and advisory_only=true.

Era 6G.1 MCP Client Compatibility Harness

app/interoperability/mcp_client_compat/ validates MCP-client-shaped interoperability transcripts locally. It defines profile shapes for:

• generic_mcp_client
• claude_desktop_shape
• cursor_shape
• vscode_shape
• openai_mcp_shape

These are profile shapes and transcript validators only. AncientOS does not require Claude Desktop, Cursor, VS Code, OpenAI tooling, or any other external client to be installed. The harness does not launch applications, open public HTTP transport, call network APIs, require credentials, or add external auth. Future live Claude/Cursor/VS Code validation is a separate track.

Compatibility checks cover initialize-shaped handshakes, tools/list, resources/list, prompts/list, default-disabled tools/call refusal, missing identity refusal, missing approval refusal, governed inspect_disk_space success when explicitly approved through the existing read-only path, deterministic error/refusal shape, no confidential material in responses, no mutation, and no network activity.

Example local usage:

python -m app.interoperability.mcp_client_compat.cli --list-profiles
python -m app.interoperability.mcp_client_compat.cli --profile generic_mcp_client
python -m app.interoperability.mcp_client_compat.cli --profile claude_desktop_shape --json

The compatibility harness adds no real MCP capabilities. The only success transcript uses the existing inspect_disk_space governed read-only lane and the existing validation fake provider shape. Mutating execution, commerce execution, network execution, automatic skill optimization, and Discord changes remain unavailable.

Invocation Candidate Lifecycle

app/interoperability/mcp_invocation/ resolves a tools/call request into an InvocationCandidate. Candidate resolution consumes the MCP tool name, arguments, requester identity, exported catalog, Rubick-shaped metadata, authorization decision, approval packet, and execution plan. It does not execute anything.

Unknown tools, missing authorization, missing approval packets, missing execution plans, mutating capabilities, commerce capabilities, non-allowlisted tools, network permission, and unregistered providers fail closed. Candidate fields explicitly include read_only, mutation_allowed = false, network_allowed = false, replay boundary, required evidence, and artifact ids.

Lich Gate Lifecycle

app/interoperability/mcp_lich_gate/ validates whether the approval packet is sufficient to proceed. Pending, rejected, expired, unknown, and missing-authority approval states fail closed. Approval metadata is not execution permission by itself. An approved read-only packet can only continue when the invocation policy already allowed the candidate. Mutating and commerce packets remain non-executable.

Zeus Evidence Gate Lifecycle

app/interoperability/mcp_zeus_gate/ requires evidence for capability registration, provider registration, authorization decision, approval packet, execution plan, and replay boundary. Missing evidence fails closed.

After an attempt, the lane produces an MCPExecutionReceipt with request, tool, capability, provider, requester, start and finish timestamps, execution status, provider invocation status, result summary, evidence ids, replay boundary, and refusal reason when applicable. Receipts redact obvious secret-bearing terms and explicitly report mutation_performed = false and network_performed = false.

Read-Only Executor Facade

app/interoperability/mcp_execution/ is the only execution entrypoint for Era 6B MCP calls. It requires:

1. Invocation candidate validation.
2. Lich gate success.
3. Zeus evidence gate success.
4. Read-only executor policy success.
5. Provider adapter allowlist success.
6. Receipt generation.

No mutating execution is available. No commerce or UCP execution is available. No filesystem mutation, network mutation, write-capable provider invocation, arbitrary shell command, Docker mutation, Git mutation, Keeper mutation, LifeVault mutation, or Naga mutation is available through this lane.

tools/call Safety Behavior

Unsupported tools, mutating tools, commerce tools, missing authorization, missing approval, missing execution planning, missing evidence, and non-allowlisted providers return structured refusals. Successful tools/call responses include the provider result and receipt. Failed governed attempts include a receipt when a candidate reached the executor facade. tools/list, resources/list, and prompts/list remain deterministic discovery surfaces.

Operator Visibility

The MCP discovery server exposes read-only visibility for discoverable tools, executable tools, blocked tools, block reasons, approval requirements, missing evidence, provider identity, and execution-policy blockers. Reports do not expose secrets, credentials, or tokens.

Era 7A Conversational Governance Intake

Era 7A introduces app/interoperability/conversational_intake/ as a transport-neutral intake layer above governed objectives, skills, capabilities, portfolio reports, lifecycle governance, and MCP enablement request models.

The intake path is deterministic and proposal-only:

operator text or object
  -> normalize request
  -> classify intent
  -> map objective, skill, and capability candidates
  -> build governed proposal
  -> recommend next step
  -> STOP for operator approval when approval is required

Supported intents include capability inspection, capability enablement, skill enablement, capability review, skill review, capability suspension, deprecation, retirement, skill explanation, capability explanation, portfolio review, lifecycle review, gap intelligence review, and unknown_intent.

Unknown or ambiguous text fails closed. The output remains structured and testable: unknown_intent, no approval requirement, execution_allowed=false, mutation_allowed=false, and recommended_next_step=ask_clarifying_question. There is no clarification loop in Era 7A; the report only includes the recommended clarifying question.

Known examples are mapped by rules:

• "Can Luna enable runtime hardware awareness?" maps to enable_skill, objective candidate improve_host_awareness, host_awareness, inspect_runtime_hardware_summary, and prepare_mcp_enablement_request.
• "Can we validate MCP clients?" maps to objective candidate validate_external_mcp_compatibility.
• "How do we reduce capability risk?" maps to objective candidate reduce_capability_risk.
• "Should we disable anything unused for 90 days?" maps to portfolio_review and build_dormancy_review.
• "Why do we have inspect_disk_space?" maps to explain_capability, inspect_disk_space, host_awareness, and explain_mapping.
• "Can we retire old disk tools?" maps to retire_capability and lifecycle_retirement_simulation.
• "Show me weak skills" maps to review_skill and skill_intelligence_report.
• "What should we build next?" maps to gap_intelligence and gap_intelligence_report.
• "What are we missing?", "What objectives are underserved?", and "What skills need work?" also map to advisory gap intelligence.

Era 7B Objective Governance

Era 7B adds app/interoperability/objective_governance/, a model-only layer for AncientObjective, success criteria, objective-skill bindings, objective-capability bindings, lifecycle simulation records, portfolio items, intelligence assessments, advisory recommendations, validation, and reports. Conversational intake can link known objective candidates such as improve_host_awareness, validate_external_mcp_compatibility, and reduce_capability_risk to objective registry records when present. This is linking metadata only; it does not alter conversational execution behavior.

Conversational intake is not a chatbot personality layer and is not Discord wiring. It makes no LLM calls, invokes no provider, applies no MCP enablement change, mutates no lifecycle record, mutates no objective, grants no automatic approval, and starts no execution. Review and report recommendations do not require approval; any later state change still requires the relevant human approval path. Enablement, suspension, deprecation, and retirement proposals require approval before follow-up work can mutate state.

Era 7C Gap Intelligence

Era 7C introduces app/interoperability/gap_intelligence/ as a transport-neutral advisory layer over objective governance, skill governance, capability registry metadata, and provider bindings.

It builds objective gap, skill gap, capability gap, governance gap, roadmap recommendation, roadmap priority, and deterministic JSON snapshot reports. Priority levels are critical, high, medium, and low, computed from signals such as objective importance, skill fitness, dormant dependencies, unresolved bindings, governance gaps, risk level, and validation coverage.

The layer is intentionally not a planner. It does not generate implementation plans, mutate roadmaps, create objectives, create skills, create capabilities, invoke providers, change lifecycle records, or add Discord or transport dependencies.