Martin Lepage, PhD
Menu
← Back to governance methods

Methods and Infrastructure

HEPHAISTOS Skill Operating System

This entry classifies the skill corpus as an operating system layer rather than a loose prompt collection. The source architecture note (`prompt engineering vs context engin.txt`) defines two coordinated engines: a Brain layer (role, execution logic, constraints, output shape) and a Map layer (knowledge retrieval, tool orchestration, memory, pruning, progressive disclosure). The SKILL files instantiate this pattern across analysis, transformation, and orchestration functions. Interpreted together, they form HEPHAISTOS: a governance runtime for bounded reasoning and output control. The key methodological contribution is architectural separation of instruction from information context so authority, traceability, and failure modes can be audited.

Methods and Infrastructure · Phase 2 · Skill operating system formalization · Methods / infrastructure architecture · Ingested from external skill corpus and architecture note · 2026

  • HEPHAISTOS
  • skill operating system
  • constrained cognitive architecture
  • prompt engineering
  • context engineering
  • tool-first routing
  • progressive disclosure

Source title preserved

prompt engineering vs context engineering + SKILL_*.md corpus

The term HEPHAISTOS is treated as an author-declared system identity for the assembled skill stack, while source filenames are preserved verbatim.

What this piece does

This piece formalizes your architectural statement: the skill stack functions as a small operating system, not a pile of prompt snippets.

Core argument

The architecture note separates two control planes:

  1. Prompt engineering as execution logic.
  2. Context engineering as information and tool routing.

That split changes what a skill is. A skill becomes a governed runtime unit with:

  • role and decision logic,
  • explicit constraints,
  • trigger conditions,
  • controlled data access,
  • deterministic tool invocation,
  • context-pruning and progressive disclosure.

On that basis, the corpus can be treated as HEPHAISTOS: a composable operating layer for bounded analysis and production.

This is why the stack should be read as a constrained cognitive architecture rather than a chatbot with extra instructions. The skill does not carry all knowledge internally; it carries routing logic toward knowledge and tools, which is the key architectural distinction.

Governance method and methodological contribution

The method contribution is the dual-engine model.

Engine A: Brain (prompt-execution layer)

This layer specifies how the unit reasons and responds:

  • role/persona,
  • task steps,
  • negative constraints,
  • output contract.

Engine B: Map (context-tool layer)

This layer specifies what the unit can know and how it can act:

  • knowledge retrieval paths,
  • tool/script routing,
  • memory policy,
  • pruning rules,
  • progressive disclosure.

The architecture note explicitly recommends tool-first routing and lightweight SKILL entrypoints with heavier references loaded on demand. That is an operational governance control: it reduces hallucination pressure, preserves token budget, and makes failure analysis more reconstructable.

Functionally, this is analogous to a cognitive split between execution and retrieval:

  • working logic and decision flow in the Brain layer,
  • structured retrieval and action affordances in the Map layer.

That separation is methodologically significant because it makes reasoning boundaries and evidence boundaries independently auditable.

System-level grouping (inferred from source files)

The current stack resolves into four families.

1. Analysis and diagnosis

  • recursive-governance-method
  • trace-investigator
  • philosopher (from SKILL_PhD.md frontmatter)
  • qualitative
  • red-team

These units inspect tensions, archives, policy drift, and governance failure points.

2. Transformation and production

  • humanize
  • peer-reviewed-paper-writer
  • publisher
  • brand-identity-system
  • novelist
  • speech

These convert diagnosis into outputs with format discipline.

3. Orchestration and utility

  • skill-pairing
  • triangulation

These coordinate staged execution or deterministic computation.

4. Academic formation layer

  • ma-degree-guide
  • philosopher

Source evidence shows distinct scope: MA guidance centers program structure and pathways, while the SKILL_PhD.md file is materially a philosophy engine.

Naming correction surfaced by the corpus

The corpus itself exposes a naming mismatch.

  • File: SKILL_PhD.md
  • Frontmatter name: philosopher
  • Body behavior: tradition mapping, debate engine, governance dilemmas, epistemic confrontation.

The runtime identity is philosophical analysis, not doctoral admissions counseling. The file name therefore carries archival history while the operative name carries execution identity.

This is exactly where dual-layer naming is required:

  • source filename preserved,
  • runtime role normalized.

Power dynamics examined

This architecture concentrates power at routing boundaries.

Who controls triggers, file maps, and tool calls controls what counts as evidence and what is allowed to execute. That means governance sits not only in answer text but in:

  • activation logic,
  • context availability,
  • script permissions,
  • pruning thresholds.

The system is safer when these controls are explicit and reviewable, because hidden routing policy functions as unaccountable authority.

The routing layer is decisive here. Governance owns final constraint authority, while philosopher and fully-rounded-power-analyst operate as co-equal right-arms: philosopher frames conceptual stakes and debate structure; power-analyst maps actors, incentives, and hidden leverage. Without that governed split, the stack would degrade into a skill drawer.

Ethical stakes

The ethical stakes are misrepresentation and silent scope drift.

If these units are framed as “just prompts,” reviewers may ignore the tool and context layers where most operational control is actually enforced. That understates both capability and risk.

Treating the stack as an operating system makes obligations clearer:

  • name the active engine split,
  • declare what is loaded,
  • declare which tools were used,
  • preserve mismatch notes (for example filename vs runtime role).

Recursive and systemic implications

HEPHAISTOS is recursively governable because each skill can be audited on two independent axes:

  • Brain axis: reasoning and instruction quality,
  • Map axis: data/tool boundaries and routing fidelity.

That enables targeted hardening. A failure can be located as:

  • logic failure,
  • context failure,
  • orchestration failure,
  • naming/trigger mismatch.

This improves maintainability and migration readiness because architecture is separated from content payload.

Current line between proto-cognitive and fully agentic behavior

The corpus now supports a proto-cognitive classification, but three capabilities remain latent rather than fully live:

  1. Persistent cross-session memory.
  2. Autonomous triggering without manual invocation.
  3. A live failure-harvesting loop that writes back into skill definitions.

The existing RECURSOTRUE governance structures suggest a pathway to all three, but those loops are not yet continuously active in this repository runtime.

Current operational baseline

As of 2026-03-30, this operating layer is anchored to a live two-surface deployment.

  • martin-lepage-phd.pharos-ai.ca carries the Hephaistos narratives, the authored governance tree, the skill ecosystem tree, and the standalone Martin-side apps.
  • pharos-ai.ca carries the PHAROS public shell, COMPASSai, AurorA, and PHAROS-side operational records such as the email baseline.

That separation matters methodologically. Narrative interpretation, authored map publication, product/service routing, and production mail operations are now documented on the surfaces that actually own them rather than being blended into one ambiguous public host.

Relation to other entries in the corpus

Why it matters

Calling this stack HEPHAISTOS is not branding language. It is a governance claim: execution logic and context routing form a coherent operating layer. Once treated that way, architecture choices become inspectable policy rather than invisible prompt craft, and live surface boundaries become part of the operating system rather than an afterthought.