-
Notifications
You must be signed in to change notification settings - Fork 1
design philosophy floor not ceiling
Language: 🇺🇸 English | 🇰🇷 한국어
Ghost-ALICE OS is not a tool for raising the ceiling of the strongest operator. It is a floor system: an agent governance layer that keeps work from falling below an acceptable quality baseline when the agent is facing an unfamiliar codebase, long documents, complex verification, or lost session context.
This viewpoint explains the design choices across the system. Some rules can feel slow to an expert operator. That friction is not the goal; it is the cost. The reward is reducing the chance that a novice-state agent drifts in scope, claims completion too early, invents new work without evidence, or skips verification.
- Core Prior
- Verification Burden
- Governance As Attachment
- Documentation Hygiene
- Tradeoff
- Related Documents
The agent is not root. An agent may propose and execute work, but it should not jump directly into unverified execution authority, completion claims, scope expansion, or new task creation.
This prior produces the operating rules below.
- Split work into semantic units first.
- Compare each unit against source, target, schema, and user constraints.
- When mismatch appears, rewind instead of pushing forward.
- Verify the necessity of new work or a new verification cycle before starting it.
- Allow completion claims only when they are connected to fresh evidence.
Complexity is measured by verification burden, not tool count.
Even a task that looks simple can be complex when it includes these conditions.
- A source must be selected.
- Source and target require interpretation or mapping.
- A schema, form, policy, or platform contract imposes strong constraints.
- A claim, number, or external behavior affects later decisions.
- Recovery is expensive if the result is wrong.
This is why Ghost-ALICE OS may require boundary setting, source locators, or completion evidence for a short request. It is not ceremony for its own sake. It prevents high-cost tasks from being treated as low-risk execution.
Verification is not final QA. Verification attaches to work while it is happening.
For example, verification-before-completion is not a static prerequisite of one specific skill. It is a runtime gate that attaches when the agent is about to claim completion. necessity-gate attaches when new work appears. If every dynamic relationship were added to the static calls graph, the graph would become crowded and lose meaning.
Ghost-ALICE OS therefore separates static relationships from runtime governance.
-
callsexpresses only stable and sparse relationships. - Re-reading, mismatch repair, and completion verification live in runtime procedure.
- Users trust evidence maps before trusting confident summaries.
Documentation is part of the system. Inaccurate docs, excessive history, and loose meta commentary can pollute agent judgment.
Public documentation follows these rules.
- Preserve current contracts rather than completion history.
- Keep deployment-specific workflow and extension internals out of core docs.
- Move long design background to wiki, issues, or private notes as appropriate.
- Use structure, not visual decoration, for emphasis.
- Prefer links and short citations over copied upstream text.
Repository docs should stay short and procedural. Wiki pages can carry design background and operating philosophy.
A floor system sacrifices some spontaneity and speed.
- Gates may be visible even for small tasks.
- Expert operators may find some checks heavy.
- Rules can feel rough when host runtimes expose different surfaces.
That cost is intentional. Ghost-ALICE OS values preventing a bad-day agent from dropping below the quality floor more than making a good-day agent sound more impressive.
AidALL/ghost-alice | This wiki stores design documents only. Runtime files live in the main repository.
- Team onboarding
- Install troubleshooting
- Windows installation tips
- Addon authoring
- Ghost-ALICE OS full design
- Design Philosophy: Floor, Not Ceiling
- Operating Model: Closed-Loop Reasoning
- Operating Model: Fallback and Escalation
- 팀 온보딩
- 설치 문제 해결
- Windows 설치 팁
- Addon 작성
- Ghost-ALICE OS 전체 설계
- 설계 철학: Floor, Not Ceiling
- 운영 모델: Closed-Loop Reasoning
- 운영 모델: Fallback and Escalation