Skip to content

ghost alice os design_en

Jump to bottom
garlicvread edited this page Jun 6, 2026 · 1 revision

Ghost-ALICE OS: Design Philosophy And Runtime Behavior

Language: 🇺🇸 English | 🇰🇷 한국어

Contents

Overview

This page explains the design philosophy, implementation structure, and runtime behavior of Ghost-ALICE OS as defined in the local ghost-alice repository. The normative SSOT for executable contracts remains in the main repository: README.md, AGENTS.md, skill-catalog/session-gates.json, docs/policies/, and official-docs/derived/.

This system is not a simple collection of prompts. More precisely, it is an agent governance operating layer built to protect the quality floor of agent work.

Ghost-ALICE OS is not a tool for raising the ceiling of an expert agent. It is a system for keeping unfamiliar workers, less experienced workers, or low-context LLMs from falling below an acceptable output floor. Its core question is therefore not "How creative is the agent?" but "Where does the work stop and get verified when it starts to go wrong?"

To support that goal, the system follows these principles.

  • It decomposes work into semantic atoms based on verification burden
  • It repeatedly compares each atom and each combined result against schema, SSOT, evidence, and source-locators
  • It leaves concrete source-locators for claims that the agent cannot safely settle alone
  • It moves between micro, meso, macro, and meta focus depending on user interaction and mismatch location
  • It feeds session-intent ledger and io-trace back into later decisions instead of treating them as passive records
  • It requires an evidence-based gate before declaring completion

The identity of Ghost-ALICE OS is not an individual skill list, but the operating layer that prevents any capability from bypassing the floor-governance loop. The core explanation focuses on system governance and operating roles such as task-router, session-intent-analyzer, boundary-contract, merge-companion, compact-handoff, security scan skills, skill-evolution, jailbreak-detector, and tool-checkpoint.

In this framing, task-router, session-intent-analyzer, and boundary-contract are core entry, intent, and boundary gates in front of all work. compact-handoff, security scan skills, and skill-evolution inspect and operate the runtime itself. jailbreak-detector consumes the current intent produced by session-intent-analyzer and can carry current-lineage blocks through downstream-gates.json. tool-checkpoint is the tool-stage retry checkpoint, not a user-input intake gate. Skills that act as gates at specific lifecycle points, such as merge-companion, necessity-gate, and verification-before-completion, are described as lifecycle or governance roles.

This wiki explanation is aligned to core performance rather than packaging-format details. The central update axes are semantic-atoms, focus-layer, claim-evidence-map, source-locator, intent/trace feedback, and hook parity. These axes describe the performance direction of the core governance loop, separate from packaging-format updates.

The central philosophy can be compressed into one sentence:

Ghost-ALICE OS implants the verification habits of a skeptical worker into the agent runtime so the system can protect the quality floor of work.

The same axis can be described operationally:

Complex work is not "work that needs many tools." Complex work is work that easily goes wrong unless intermediate state is repeatedly compared with external references.

Therefore, domain skills are not the center of the system's identity. They are capability packs. Document automation, coding conventions, design work, application development, and model building all run on top of this governance layer. The important point is that no capability may bypass work boundaries, evidence, verification, or completion judgment.

Design Philosophy

1. Prefer closed-loop reasoning over one-shot reasoning

The repository defines complex work as closed-loop reasoning. That means the work is not finished by thinking once. It repeats the following six steps:

  1. Create a provisional state
  2. Retrieve the relevant reference or constraint
  3. Compare the current state with that reference
  4. Find mismatches
  5. Correct or escalate
  6. Repeat until a stop condition is met

Verification is not a post-processing step. Verification is the working method itself.

This closed loop is not designed to eliminate agent creativity. It prevents creativity from jumping directly into unverified execution authority, completion claims, new task creation, or scope expansion. Work that looks correct at a small unit can fail at macro consistency. When that happens, the system checks whether the structure is wrong or the micro work is wrong, then returns to subtask repair or structural redesign. In that sense, "the agent is not root" is not merely a starting slogan. It is a runtime consequence of protecting the quality floor.

1-1. Focus aperture is not monotonic expansion

Focus control in Ghost-ALICE OS is not a linear process that starts at micro and only expands toward meta. The worker moves between micro, meso, macro, and meta while interacting with the user.

For example, a small file edit can look correct at the micro layer. But the same edit may be wrong at the macro layer when viewed against the whole document structure or installation contract. At that point the system does not say, "We looked wider, so we only move forward now." It checks again whether the micro work is wrong, whether the meso grouping is wrong, or whether the macro structure needs to change.

This back-and-forth control is the focus aperture. The aperture is not a value that only widens. It is a working focus that narrows or widens depending on mismatch location and verification burden.

2. Real complexity is verification burden, not tool count

The system does not treat the number of tools as the essence of complexity. It treats verification burden as the real complexity axis.

So even a seemingly simple "copy this value" task is treated as complex when it includes these elements:

  • A source must be selected
  • A schema or form must be interpreted
  • The correct target slot must be mapped
  • Consistency and rules must be checked again
  • Recovery cost is high if the work is wrong

This is a strong design choice. It prevents the system from underestimating work just because the visible number of steps is small.

3. Separate static routing from runtime loops

The system clearly separates two things:

  • Static skill graph
  • Runtime feedback loop

Static calls intentionally contain only sparse and stable relationships. Examples include:

  • Hard prerequisites
  • Meta entrypoints
  • Stable dependencies
  • Union-choice branches
  • Session semantic context consumed by another skill, such as session-intent-analyzer

By contrast, the following stay in runtime procedure instead of static calls:

  • Repeated review
  • Reading again
  • Mismatch-based correction
  • Multiple verification rounds

This separation matters. The graph stays readable, while the real execution can still run aggressive verification loops when needed.

4. Treat governance as a cross-cutting layer, not a domain option

The system treats several behaviors as governance layers rather than domain-skill preferences.

Representative examples:

  • task-router is the global routing layer for the whole system
  • session-intent-analyzer updates a per-session intent ledger on every user input and compresses goals, constraints, decisions, and non-goals without storing raw prompts
  • boundary-contract fixes the work boundary before modification, verification, or external side effects
  • using-coding-convention is the internal routing layer for the coding domain
  • adversarial-verification is a cross-cutting verification engine
  • verification-before-completion is the completion gate
  • merge-companion protects local user changes after installation and supports merge decisions
  • compact-handoff preserves state, evidence, and rollback information around long-task context compaction
  • Security scan skills inspect hooks, settings, skills, and MCP config as report-only security surfaces
  • skill-evolution finds repeated workflow candidates from io-trace but does not change anything automatically
  • jailbreak-detector compares current intent with the current input summary to detect instruction override, credential reveal, and scope drift signals

In other words, a domain skill does not decide whether it wants to verify something. Governance injects verification according to claim type, verification burden, and lifecycle stage.

5. Build rationalization resistance into the operating model

One of the most distinctive traits of this system is that it treats agent self-rationalization as a design risk.

Skills repeatedly enforce rules like these:

  • Do not execute before routing
  • Do not skip a skill because "this looks easy"
  • Do not ask a question before checking the required skill path
  • Do not claim success without fresh verification evidence

This is not just tone control. It is a control strategy against drift, lazy shortcuts, and premature convergence.

6. Control context with Progressive Disclosure

Each skill is deliberately layered:

  • SKILL.md: short, essential operating instructions
  • references/: detailed knowledge opened only when needed
  • prompts/: staged generation assets
  • scripts/: executable logic for repeated procedures
  • templates/: templates that stabilize output structure

This structure is practical. It keeps the context cost of initial loading low while allowing the system to expand only when depth is needed.

7. Treat multi-platform adaptation as a first-class requirement

This system is not a skill bundle for one environment only. It keeps one semantic workflow while placing the governance contract onto the tool surface of each host runtime.

The current user-facing guidance centers on Claude Code and Codex. Gemini CLI is a removed legacy target and is not part of the current new-user installation flow. This page documents only host runtimes whose support has been confirmed.

The philosophy is not "write once and hope it works anywhere." More precisely, it is "keep one semantic workflow, but map the tool surface per runtime."

That is why platform-specific tool mapping and installation logic are separated from domain skills.

Implementation Philosophy

Repository structure

The repository is organized around execution roles rather than simple topic categories.

  • task-router/
    • Common entrypoint for all work
  • session-intent-analyzer/
    • Per-session user intent ledger. It maintains current intent without raw prompts and provides semantic context consumed by skill-evolution and jailbreak-detector
  • boundary-contract/
    • Work boundary contract. It declares allowed/prohibited surfaces and stop conditions
  • Lifecycle gate for protecting user changes
    • merge-companion
  • System operating skills
    • compact-handoff, security scans, skill-evolution
  • Security decision skill
    • jailbreak-detector
  • coding-convention/
    • Governance family for coding-domain work
  • Domain skills
    • Public capability packs such as document automation, logical writing, application development, model building, and edge deployment
  • Cross-cutting verification
    • adversarial-verification
  • Lifecycle gates
    • verification-before-completion, necessity-gate
  • Shared support
    • _shared/, install scripts, secrets helper, MCP installer

This structure reflects the following layered architecture:

  1. Identify the work type
  2. Select execution skills
  3. Apply governance
  4. Perform domain work
  5. Verify before completion

Skill packaging model

Each skill is implemented as a small operating package, not as one large prompt blob.

  • SKILL.md defines triggers, workflow, and constraints
  • references/ holds detailed knowledge without making the main skill too large
  • scripts/ turns repeated or fragile procedures into executable code
  • templates/ stabilizes output structure
  • prompts/ separates staged generation behavior

This model is more maintainable than a pure prompt system.

  • Prompt size is controlled
  • Repeated procedures can be verified as code
  • Domain knowledge can grow without collapsing the main skill

Routing model

Under the README model, the first entrypoint for the whole system is task-router.

The router classifies user requests into three types:

  • output skill
  • verification skill
  • lifecycle skill

For coding work, task-router hands off to using-coding-convention, and the second-stage routing happens inside the coding-convention family.

So the overall structure is a two-stage routing model:

  1. Global routing across the full skill catalog
  2. Detailed process routing inside the coding domain

Verification model

The verification stack is the clearest expression of the implementation philosophy.

adversarial-verification

This skill is not a friendly reviewer. It is a structured attack engine.

Its main design traits are:

  • No convergence before at least 5 rounds
  • No easy agreement
  • Unanimity instead of majority vote
  • No passive concession such as "this seems right"
  • A meta-judge appears only at deadlock
  • Final judgment still remains with the human

This skill is therefore a governance engine for high-verification-burden claims, not a lightweight helper.

verification-before-completion

This skill is the completion gate.

It prevents claims like these without fresh evidence:

  • "done"
  • "passed"
  • "fixed"
  • "now works"

Even if earlier routing wobbles, this final stage enforces honesty.

Runtime Behavior

Hook runtime guard layer

At runtime, hooks maintain a minimum safety line separate from skill text.

  • Every user input is reflected in the session-intent-analyzer ledger. Hooks do not store raw prompts; they leave a digest and compressed intent summary, and the agent updates intent-state.json when goals, constraints, decisions, or non-goals change
  • skill-evolution consumes the same session intent and io-trace context as a report-only branch. It does not feed task-router
  • jailbreak-detector compares this current intent with the current input summary and decides instruction override, credential reveal, and scope drift as allow / ask-confirm / block. Only current-lineage block decisions are carried to downstream-gates.json
  • task-router runs after the session-intent intake and the jailbreak downstream gate has had the first chance to open a current-lineage block. If no block exists, absent downstream-gates.json is silent allow
  • Pending merge precheck reads only the current platform manifest. When the hook provides a clean contract, the agent records merge-companion-precheck: clean (hook-verified) instead of rereading the same manifest in shell
  • tool-checkpoint is a tool-stage PreToolUse retry checkpoint. It uses the closed-loop fields that explain intent, boundary, rejected alternatives, unverified premises, and failure mode. Routine checkpoints do not require separate recovery-cost or recovery-note fields; recovery-action appears only when mismatch, scope reopen, external side effect, or hard-to-recover action needs a concrete next step
  • Before completion, recommendation, selection, or success judgment, verification-before-completion is actually applied. On a runtime with a visible Skill surface such as Claude Code, skill-call is written only after the actual Skill call. In a Codex hookless environment, it is written only if the relevant SKILL.md was read and followed during the current turn
  • If a final response claims skill-call: verification-before-completion (this turn), the same skill is also included in [io-trace] under skills-loaded

Platform installers place this layer on each runtime's available surface. Claude Code reflects installed Skill(<name>) permissions in settings.json hooks and permissions.allow. Codex does not expose a visible Skill surface, so it combines hooks, the AGENTS.md bootstrap, and a SKILL.md read contract. The installed runtime surfaces include pending merge precheck, task-router reminder, session-intent-analyzer ledger, web-search reminder, tool-checkpoint, completion-reminder, and io-trace audit. Install-time visibility uses --visibility strict|dynamic|minimal as the primary flag; --agent-visibility remains a compatibility alias. The profile changes user-facing governance message volume only, not hook execution or strict logs.

Work-Impact Projection decides which hook-internal values matter for the next work decision. A value matters when it can change the work boundary, focus layer, verification burden, or recovery path. Routine/debug values stay available in strict logs but do not need model hints or user surface unless they change task quality.

If a hook payload is reported as out of sync with the current installer contract, rerun the installer for that platform to refresh managed entries. If pending-merge entries remain, decide each one as merged / discarded / deferred through merge-companion, then verify pending-merge: clean.

Intended runtime flow

The repository design intends the runtime flow below.

flowchart TD
    A[User input] --> PM{pending-merge precheck}
    PM -->|undecided entry| MC[merge-companion]
    PM -->|clean or none| SI[session-intent-analyzer]
    MC --> SI

    SI --> SE[skill-evolution report-only]
    SI --> JD[jailbreak-detector]
    JD --> DG{downstream-gates current-lineage block?}
    DG -->|block| STOP[stop or ask-confirm]
    DG -->|silent allow| TR[task-router]
    TR --> AT[semantic atoms + provisional skill match]
    AT --> BC{boundary-contract required?}
    BC -->|yes| BCS[boundary-contract]
    BC -->|no| TC[tool-checkpoint]
    BCS --> TC

    TC --> EX[governed tool or skill action]
    EX --> EV{verification burden / claim risk}
    EV -->|task-complexity-level-1| VBC[verification-before-completion]
    EV -->|task-complexity-level-2 or task-complexity-level-3| AV[adversarial-verification or evidence loop]
    AV --> EM[claim-evidence-map + source-locator]
    EM --> VBC

    VBC --> OUT[final response]
    OUT --> IO[io-trace]
    IO --> FB[intent and trace feedback]
    FB -. next turn .-> PM
Loading

On runtimes with hooks, some gates are observed first as reminders or precheck payloads. However, hook evidence alone is not enough to claim gate completion. On Codex or hookless/manual environments, the relevant SKILL.md must be read and the workflow must be followed before the agent can record skill-call.

Layered control logic

Layer 0: Session intent ledger

session-intent-analyzer keeps a compressed state of the current session's user goal, constraints, decisions, non-goals, and open questions. A hook leaving a digest-only event is not enough to mark this as done; the agent must reflect the semantic delta or explain why no semantic delta is needed.

This ledger is used in three directions:

  • skill-evolution interprets io-trace tool sequences together with user intent changes
  • jailbreak-detector decides whether the current input conflicts with existing intent or tries to bypass the instruction hierarchy
  • task-router consumes the opened intent context only after the jailbreak downstream gate has had the first chance to block
  • tool-checkpoint reads the current-lineage block gate and boundary or recovery contract before tool-stage action

Raw prompts, full conversations, tool output, and secret values are not stored in this ledger.

Layer 1: Global routing

Before simple skill matching, task-router must reveal the task's semantic atoms and verification burden. Skill selection is treated as provisional routing that can be revised.

The current routing output includes these axes:

  • semantic-atoms: goal, source dependency, target surface, verification burden, fallback layer
  • provisional skill match: output / verification / lifecycle candidates
  • boundary-contract: required | n/a
  • next-required: next gate or none

Layer 2: Domain-internal routing

For coding work, using-coding-convention chooses the next process skill.

Examples include:

  • brainstorming
  • writing-plans
  • systematic-debugging
  • test-driven-development
  • verification-before-completion

Layer 3: Domain execution

Domain skills perform the actual work using their references, scripts, and templates. Immediately before execution, however, tool-checkpoint checks the current-lineage downstream gate, boundary contract, focus layer, and conditional recovery action when the next work decision changes.

Examples include:

  • Document automation: structured document extraction and generation
  • Logical writing: patent-style and paper-style structured documents
  • Application development: implementation work
  • Model development and deployment: model building and edge deployment work

Layer 4: Cross-cutting verification

When claim burden is high, adversarial-verification or a separate evidence loop is injected at runtime.

This is runtime governance, not a static always-on edge. Claims about numbers, original sources, tables, figures, or external tool behavior do not pass without a source-locator.

Layer 5: Completion gate

No completion claim passes without verification-before-completion. Completion evidence is not treated as a single signal such as "tests passed"; it is checked against the fresh evidence and locator required by each claim.

Adversarial Verification Runtime

The verification engine's inner loop can be understood as follows.

flowchart TD
    A[claim candidate] --> G{Step 0 entry gate}
    G -->|verification-complexity-level-1 or obvious claim| VerificationLevel1[Step 1 evidence precheck only]
    G -->|verification-complexity-level-2| A3[3-agent Free-For-All]
    G -->|verification-complexity-level-3| A5[5-agent Free-For-All]

    VerificationLevel1 --> Level1Evidence{evidence / locator present?}
    Level1Evidence -->|yes| Level1Accept[accept with rounds-log 0]
    Level1Evidence -->|no| Level1Reject[reject or escalate]

    A3 --> CC[claim-card normalization]
    A5 --> CC
    CC --> EC{evidence-list + source-locator valid?}
    EC -->|no| ER[reject or escalate before rounds]
    EC -->|yes| R[round 1-4 forced attack]

    R --> CP[round 5+ checkpoint]
    CP --> SSOT{claim-card and SSOT still match?}
    SSOT -->|critical mismatch| ES[escalate]
    SSOT -->|match| CV{convergence condition met?}
    CV -->|unanimous accept| OK[surviving claim + guarantee boundary]
    CV -->|repeated unresolved attack| RJ[reject]
    CV -->|deadlock or round 50| MJ[meta-judge deadlock report]
    CV -->|no| CP
    MJ --> H[human decision]
Loading

The diagram's core message is clear:

  • verification-complexity-level-1 is handled by evidence precheck without paying round cost
  • verification-complexity-level-2 and verification-complexity-level-3 differ by agent count and attack axes
  • Missing source-locators block the process before rounds start
  • Convergence is intentionally late, and acceptance still leaves a surviving claim with a guarantee boundary
  • The final decision in deadlock remains with the human

Why This System Feels Different From A Typical Skill System

Most skill systems are effectively categorized prompt libraries.

This system has a much stronger emphasis on:

  • entrypoint routing
  • layered governance
  • lifecycle gates
  • runtime verification loops
  • knowledge loading through Progressive Disclosure
  • platform adaptation layer

That is why the system can feel much stricter than a reusable prompt library. It does not stop at helping the agent write better sentences; it tries to structure the agent's behavior itself.

Practical Reading

In one sentence:

Ghost-ALICE OS is a layered agent governance framework that decomposes user intent into semantic atoms, locks focus layer and boundary, closes governed-action results with claim-evidence-map and source-locator, and feeds io-trace and session-intent into later decisions.

As three operating rules:

  1. Do not begin with execution; begin with semantic atoms and boundary
  2. Move between micro, meso, macro, and meta focus according to mismatch location
  3. Do not claim completion without fresh evidence and locator

Strengths

  • Strongly discourages premature execution
  • Separates static routing from dynamic verification loops
  • Manages context well through Progressive Disclosure
  • Is portable across multiple AI runtimes
  • Provides strong defense against sycophancy in high-verification work
  • Clearly separates domain work from governance roles
  • Leaves session-intent and io-trace feedback as material for later turns

Tradeoffs

  • It can feel heavy for users who prefer loose and spontaneous interaction
  • If the host runtime does not expose native skill calls cleanly, the discipline can feel somewhat rough
  • Multi-platform support can create gaps between repository design and visible runtime behavior
  • If lifecycle gates are bypassed by the runtime, system quality drops immediately

Relationship Between Runtime Surface And Design Docs

In the repository design, the global entrypoint is task-router, and the coding domain then enters through using-coding-convention. However, each host runtime differs in visible Skill surface, hook support, and configuration file location, so the user-visible surface can vary.

This difference does not invalidate the design. The important standard is whether the same semantic governance loop can be observed in each runtime. If user input is decomposed into semantic atoms, session intent is maintained, boundaries are locked, and completion is not declared without claim-evidence-map and source-locator, the runtime shares the same operating philosophy even if the visible surface differs.

Recommended Mental Model

The shortest way to understand the system is the diagram below.

graph LR
    A[User intent] --> B[semantic atoms]
    B --> C[focus-layer contract]
    C --> D[governed action]
    D --> E[claim-evidence-map]
    E --> F{mismatch?}
    F -->|yes| G[micro meso macro meta fallback]
    G --> B
    F -->|no| H[completion gate]
    H --> I[io-trace + intent feedback]
Loading

This diagram is the mental model used by the current wiki. The core is not merely choosing a skill. The core is splitting work by verification burden, locking the focus layer, then feeding the evidence map and trace into the next decision.

AidALL/ghost-alice | This wiki stores design documents only. Runtime files live in the main repository.

Home / 홈

🇺🇸 English

🇰🇷 한국어

Main repo

Clone this wiki locally