https://chatgpt.com/share/69f21e9f-bab0-83eb-8011-13757a26240e  
https://osf.io/q8egv/files/osfstorage/69f22fba45d47f96d7d94f4f

From Requirements to Runtime Kernels Engineering - Implementation Example with SKILL.md

 

(A) Plan for Writing the Conversion Skill

Master Skill + Internal Sub-Skills for Differential-Topological Kernel Compilation

The future SKILL.md should behave like a semantic compiler, not a prompt generator.

---

0. Core Decision

Recommended architecture

One Master Skill
+ internal routing modes
+ input-class adapters
+ pipeline subroutines
+ output-pattern library
+ audit layer

Not:

Many independent disconnected Skills

At least for the first version, one master Skill is better because the whole method depends on shared concepts:

• Kernel as meta-attractor

• topology lexemes as procedural attractors

• opcode validity rule

• anti-over-topology gate

• residual audit

• instruction hierarchy safety

• compression trace

If these are split too early into many separate Skills, consistency will degrade.

The better structure is:

Master Skill = Router + Shared Theory + Compiler Pipeline + Output Contracts

Then inside it:

Sub-skills = modes / phases / adapters, not separate files at first

---

1. Master Skill Purpose

The master Skill should be named something like:

Differential-Topological Kernel Compiler

or:

Attractor-Lexeme Kernel Compiler

Its purpose:

Convert complex requirements, theory frameworks, long prompts, doctrines, or workflows into compact Kernel prompts using valid topology-inspired opcodes, while preserving intent, boundaries, and residual uncertainty.

The master Skill should define the global law:

Act as a semantic compiler, not a prompt decorator.

Its core equation:

RequirementSource → SemanticCompiler → KernelIR → ExecutableKernel + AuditTrace. (1.1)

---

2. Why a Master Skill Is Needed

A master Skill is needed because the conversion has common reusable contents:

2.1 Shared Concepts

These should be defined once:

Kernel
Meta-attractor
Procedural attractor
Opcode
Kernel IR
Boundary
Curvature
Attractor
Residual
Compression trace
Anti-over-topology gate

2.2 Shared Rules

These should also be defined once:

No topology without operation.
No compression without intent preservation.
No Kernel without residual audit.
No Kernel authority above system / safety / user boundaries.
No decorative mathematical language.

2.3 Shared Pipeline

All conversions reuse the same broad pipeline:

Gate → Intent → Boundary → Curvature → Attractor → Opcode → KernelIR → Compression → Audit → Translation

So the master Skill must own this pipeline.

---

3. Recommended Skill Hierarchy

The future Skill should be written as one SKILL.md with these internal layers:

Layer 1: Master Router
Layer 2: Input-Class Adapters
Layer 3: Compiler Pipeline Subroutines
Layer 4: Opcode Dictionary
Layer 5: Kernel Pattern Library
Layer 6: Audit Layer
Layer 7: Output Templates

Visual structure

User Input
   ↓
Master Router
   ↓
Input-Class Adapter
   ↓
Compiler Pipeline
   ↓
Opcode Dictionary
   ↓
Kernel IR Composer
   ↓
Compression Engine
   ↓
Audit Layer
   ↓
Final Output Package

---

4. Layer 1 — Master Router

The master router decides what kind of conversion request the user is making.

It should classify the request into one of several modes.

4.1 Input Classes

A. Practical Requirement
B. Theory Framework / Article
C. Long Prompt
D. Domain Doctrine / Policy / Standard
E. Workflow / Process
F. Hybrid Input
G. Simple Task — No Kernel Needed

4.2 Routing Formula

InputMode := classify(UserInput). (4.1)

Then:

if SimpleTask → refuse over-topology; provide plain prompt
if PracticalRequirement → Requirement Adapter
if TheoryFramework → Theory Adapter
if LongPrompt → Prompt Compression Adapter
if DomainDoctrine → Doctrine Adapter
if Workflow → Workflow Adapter
if Hybrid → Hybrid Adapter

4.3 Router Output

The router should produce:

Detected input class
Suitability decision
Reason for route
Selected compiler mode

Example:

Input Class: Theory Framework
Suitability: Use Kernel
Reason: concept-heavy, cross-domain, needs reusable reasoning structure
Selected Mode: Theory-to-Kernel Compiler

---

5. Layer 2 — Input-Class Adapters

These are not separate full Skills yet. They are internal adapters.

Each adapter uses the common pipeline but adjusts what to extract.

---

5.1 Requirement Adapter

Use when the input is a practical user requirement.

Extract

Objective
Domain
Actors
Inputs
Outputs
Constraints
Risks
Success criteria
Implementation path

Typical Kernel Pattern

ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual.

Best for

software requirements
business workflows
legal / accounting analysis tasks
AI agent tasks
document processing
decision support

---

5.2 Theory Framework Adapter

Use when the input is an article, paper, theoretical framework, or conceptual system.

Extract

Core thesis
Key definitions
Assumptions
Concept hierarchy
Tension structure
Transformation logic
Invariants
Applications
Residual theoretical gaps

Typical Kernel Pattern

TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.

Best for

SMFT articles
management theories
philosophical frameworks
AI design theories
cross-domain conceptual frameworks

---

5.3 Long Prompt Adapter

Use when the input is already a long prompt and the user wants it compressed.

Extract

Role identity
Task objective
Rules
Output format
Examples
Safety boundaries
Repeated patterns
Redundant wording
Critical constraints

Typical Kernel Pattern

PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.

Best for

system prompts
assistant prompts
agent prompts
workflow prompts
Codex / tool prompts

---

5.4 Domain Doctrine Adapter

Use when input is a policy, professional standard, legal test, accounting rule, medical guideline, internal protocol, or governance doctrine.

Extract

Authority source
Scope
Definitions
Decision rules
Exceptions
Boundary conditions
Evidence requirements
Compliance risks
Residual ambiguity

Typical Kernel Pattern

DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.

Best for

legal doctrines
accounting standards
compliance policies
corporate rules
evaluation rubrics
technical standards

---

5.5 Workflow Adapter

Use when the input describes a process or desired operational flow.

Extract

Start state
End state
Actors
Steps
Decision gates
Failure modes
Feedback loops
Outputs
Residual handoffs

Typical Kernel Pattern

WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.

Best for

business processes
AI pipelines
document workflows
agent orchestration
review cycles
approval processes

---

5.6 Hybrid Adapter

Use when the input combines theory and implementation.

Extract

Theory layer
Execution layer
Bridge concepts
Operational translation
Concept-to-action mapping
Invariants
Risks of distortion
Residual theoretical gaps

Typical Kernel Pattern

HybridKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→runtime projection→residual.

Best for

turning an article into a Skill
turning a philosophy into an AI framework
turning a theory into a product workflow
turning SMFT into prompt engineering

This is probably the most important mode for your use case.

---

6. Layer 3 — Compiler Pipeline Subroutines

These are the true sub-skills.

They support all input adapters.

6.1 Subroutine 0 — Suitability Gate

Purpose:

Decide whether Differential-Topological Kernel conversion is justified.

Checks:

Is the input complex?
Is it multi-constraint?
Is it theory-heavy?
Does it require stable repeated reasoning?
Is there hidden tension?
Would topology terms improve structure?
Would plain prompting be better?

Formula:

KernelNeed := Complexity + Ambiguity + ConstraintLoad + CrossDomainMapping + StabilityNeed. (6.1)

Use Kernel only if:

KernelNeed > SimplicityThreshold. (6.2)

Output:

UseKernel / UsePlainPrompt / UseHybrid

---

6.2 Subroutine 1 — Intent Extractor

Purpose:

Extract what the user actually wants before applying topology.

Extract:

Objective
Output type
Audience
Domain
Success criteria
Must-preserve contents
Must-avoid contents

Formula:

IntentCore := Objective + Domain + OutputNeed + Audience + SuccessCriteria. (6.3)

---

6.3 Subroutine 2 — Boundary Mapper

Purpose:

Find constraints, scope limits, exclusions, authority hierarchy, and safety boundaries.

Extract:

Scope boundary
Domain boundary
Authority boundary
Output boundary
Risk boundary

Formula:

Boundary := Scope + Constraints + Exclusions + AuthorityHierarchy + SafetyLimits. (6.4)

---

6.4 Subroutine 3 — Curvature Scanner

Purpose:

Detect hidden tension, contradiction, nonlinear complexity, ambiguity, or assumption failure.

Detect:

goal conflict
domain mismatch
compression loss
safety tension
implementation ambiguity
evidence gap
theory-to-practice distortion

Formula:

Curvature := NonlinearTension + Contradiction + Ambiguity + HiddenDependency. (6.5)

---

6.5 Subroutine 4 — Attractor Selector

Purpose:

Choose the stable convergence target of the Kernel.

Examples:

Executable solution
Conceptual framework
Prompt compression
Decision procedure
Workflow trace
Theory-to-practice bridge

Formula:

Attractor := DominantStablePurpose + OutputConvergencePoint. (6.6)

Important:

Wrong attractor = wrong Kernel.

---

6.6 Subroutine 5 — Opcode Mapper

Purpose:

Convert extracted structure into valid topology-inspired opcodes.

Rule:

Every opcode must have operation and output evidence.

Formula:

ValidOpcode := Lexeme + RequiredOperation + OutputEvidence. (6.7)

Example:

boundary → identify constraints → output boundary list
curvature → identify nonlinear tension → output curvature points
attractor → select stable direction → output dominant attractor
residual → identify unresolved remainder → output residual audit

---

6.7 Subroutine 6 — Kernel IR Composer

Purpose:

Compose a safe intermediate Kernel before compression.

Kernel IR components:

Runtime identity
Objective
Opcode stack
Boundary rules
Output contract
Residual audit instruction

Formula:

KernelIR := RuntimeIdentity + Objective + OpcodeStack + BoundaryRules + OutputContract + ResidualAudit. (6.8)

---

6.8 Subroutine 7 — Compression Engine

Purpose:

Produce Full, Compact, and Minimal Kernel forms while preserving structure.

Compression levels:

Full Kernel — safer, readable
Compact Kernel — practical reuse
Minimal Kernel — token-efficient

Formula:

Compression := RemoveRedundancy + PreserveOpcodeOrder + PreserveBoundary + PreserveAudit. (6.9)

---

6.9 Subroutine 8 — Audit Layer

Purpose:

Check the generated Kernel for stability, safety, residual gaps, and over-topology.

Audits:

Suitability audit
Intent audit
Opcode audit
Boundary audit
Compression audit
Stability audit
Residual audit
Over-topology audit

Formula:

KernelQuality := IntentPreservation + Executability + Stability + Minimality + ResidualHonesty − DecorativeTopology − DriftRisk − AuthorityMisfire. (6.10)

---

6.10 Subroutine 9 — User-Facing Translator

Purpose:

Translate topology-rich Kernel logic into user-readable explanation.

Example:

Internal: detect curvature.
External: find hidden contradictions and nonlinear tensions.

Internal: select attractor.
External: identify the main stable output direction.

Internal: audit residual.
External: list what remains unresolved.

This subroutine prevents the Skill from becoming unreadable.

---

7. Layer 4 — Opcode Dictionary

The Skill needs a shared opcode dictionary.

This should not be too large in v1.

A good v1 dictionary should have three reliability tiers.

---

7.1 Tier 1 — High-Reliability Core Opcodes

These should appear frequently.

Opcode	Function
Kernel	Runtime execution identity
Intent	Preserve objective
Boundary	Detect scope and constraints
Curvature	Detect hidden tension
Attractor	Select stable convergence
Projection	Convert structure into output
Residual	Audit unresolved remainder
Invariant	Preserve non-negotiable identity
Flow	Describe process path

These are safe and broadly useful.

---

7.2 Tier 2 — Medium-Reliability Opcodes

Use when context justifies them.

Opcode	Function
Manifold	Multi-dimensional problem space
Coordinate	Key variables / axes
Bifurcation	Decision branch
Basin	Scope of attractor
Singularity	Irreducible contradiction
Phase-lock	Alignment among components
Gradient	Direction of strongest change
Compression	Reduce while preserving structure

These are useful but need context.

---

7.3 Tier 3 — Specialized Opcodes

Use sparingly.

Opcode	Function
Holonomy	Loop consistency after iteration
Fiber	Local-to-global structure
Cobordism	Bridge between structured states
Gauge	Choice of representation / frame
Torsion	Directional twist / path-dependent distortion
Sheaf	Local consistency across overlapping regions

These should not be used in general-purpose Kernels unless the input truly warrants them.

---

8. Layer 5 — Minimal Kernel Pattern Library

The Skill should include a small library of reusable patterns.

These are not separate Skills. They are templates selected by the router.

---

8.1 Requirement Kernel Pattern

ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual. Preserve intent; no decoration.

Use for:

requirements
software tasks
business analysis
document workflows
decision support

---

8.2 Theory Kernel Pattern

TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.

Use for:

articles
papers
philosophical frameworks
SMFT-style theories
management theories

---

8.3 Prompt Compression Kernel Pattern

PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.

Use for:

long prompts
system prompts
agent prompts
workflow prompts

---

8.4 Doctrine Kernel Pattern

DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.

Use for:

law
accounting
compliance
policy
standards

---

8.5 Workflow Kernel Pattern

WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.

Use for:

processes
pipelines
agent workflows
review / approval systems

---

8.6 Hybrid Theory-to-Skill Kernel Pattern

This is the most relevant for your current project.

Theory→SkillKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→Skill IR→residual.

Use for:

turning a theory article into a Skill
turning a framework into a prompt system
turning SMFT concepts into engineering instructions

---

9. Layer 6 — Audit Layer

The audit layer should be mandatory.

Every conversion should end with at least a compact audit.

9.1 Audit Categories

Suitability
Intent preservation
Boundary correctness
Opcode validity
Compression loss
Residual honesty
Over-topology risk
Authority safety
User readability

9.2 Anti-Decorative Rule

The Skill should enforce:

Delete any topology term that does not perform work.

Formula:

InvalidOpcode := Lexeme − Operation. (9.1)

9.3 Residual Rule

Every Kernel must include residual audit unless the task is trivial.

Formula:

KernelWithoutResidual := IncompleteKernel. (9.2)

9.4 Authority Rule

Every Kernel is subordinate to higher instructions.

Formula:

SystemRules > DeveloperRules > SafetyRules > UserIntent > KernelPrompt > Formatting. (9.3)

---

10. Layer 7 — Output Templates

The Skill should support three output depth levels.

---

10.1 Full Output

For serious conversions.

1. Suitability
2. Detected Input Class
3. Extracted Intent
4. Boundary Conditions
5. Curvature Points
6. Dominant Attractor
7. Opcode Map
8. Full Kernel
9. Compact Kernel
10. Minimal Kernel
11. Compression Trace
12. Residual Audit

---

10.2 Compact Output

For normal use.

Input Class:
Intent:
Opcode Stack:
Full Kernel:
Minimal Kernel:
Residuals:

---

10.3 Minimal Output

For advanced users.

Kernel:
[Minimal Kernel]

Trace:
Intent → Boundary → Curvature → Attractor → Residual

---

11. Should We Write Several Separate Skills?

11.1 Initial Answer: No, Not Yet

Do not start with many separate Skills.

The first real deliverable should be:

One Master SKILL.md

with internal sections.

Reason:

The method is still young.
Shared concepts must remain centralized.
Splitting too early creates inconsistency.

---

11.2 Later Version: Yes, Split After Stabilization

After the master Skill is tested, it can be split into a Skill pack.

Possible future files:

SKILL.md — Master Router
opcode_dictionary.md — shared opcode definitions
input_adapters.md — requirement / theory / prompt / doctrine / workflow adapters
kernel_patterns.md — reusable minimal patterns
audit_checklists.md — stability and residual checks
examples.md — worked examples

But that should be v2 or v3.

---

11.3 Possible Future Skill Pack

Master Skill

Differential-Topological Kernel Compiler

Responsible for:

routing
shared concepts
final output
audit enforcement

Sub-Skill 1

Requirement-to-Kernel Compiler

Sub-Skill 2

Theory-to-Kernel Compiler

Sub-Skill 3

Prompt-to-Minimal-Kernel Compressor

Sub-Skill 4

Doctrine-to-Decision-Kernel Compiler

Sub-Skill 5

Workflow-to-Runtime-Kernel Compiler

Sub-Skill 6

Kernel Audit and Compression Checker

But again: this should come later.

---

12. Recommended v1 Structure for Actual SKILL.md

The next prompt should ask for a single master Skill with this structure:

# Differential-Topological Kernel Compiler

## Purpose

## Core Principle

## When to Use

## When Not to Use

## Required Output Modes

## Master Routing Logic

## Input Class Adapters

### Practical Requirement Adapter
### Theory Framework Adapter
### Long Prompt Adapter
### Domain Doctrine Adapter
### Workflow Adapter
### Hybrid Adapter

## Compiler Pipeline

### 0. Suitability Gate
### 1. Intent Extraction
### 2. Boundary Detection
### 3. Curvature Detection
### 4. Attractor Selection
### 5. Opcode Mapping
### 6. Kernel IR Composition
### 7. Compression
### 8. Audit
### 9. User-Facing Translation

## Opcode Dictionary

## Kernel Pattern Library

## Audit Rules

## Output Templates

## Examples

## Failure Modes

## Final Behavioral Rules

This should be written as an actual Skill file, not an article.

---

13. What the Actual Skill Should Emphasize

The future SKILL.md should repeatedly enforce these principles:

13.1 It is a compiler

Treat conversion as compilation from semantic source to Kernel IR.

13.2 It preserves intent first

Never topologize before extracting intent.

13.3 It uses topology only when useful

Use topology terms only when they perform a concrete operation.

13.4 It routes input classes

Different input classes require different adapters.

13.5 It audits compression loss

Every compressed Kernel must report what may have been lost.

13.6 It outputs both Kernel and trace

The user must see not only the final Kernel, but how it was derived.

---

14. Writing Plan for the Next Prompt

The next prompt can ask for:

Write the full SKILL.md for the Differential-Topological Kernel Compiler according to the architecture plan above.

The generated Skill should include:

1. Master Skill definition
2. Routing logic
3. Input adapters
4. Pipeline phases
5. Opcode dictionary
6. Kernel patterns
7. Audit checklist
8. Output templates
9. Examples
10. Failure-mode controls

The first version should be complete but not too bloated.

Target style:

Operational
Direct
Reusable
Instruction-like
Not essay-like
Not too theoretical

Approximate length:

2,500–4,500 words

Not too short, because the Skill is complex.

Not too long, because a Skill must guide execution.

---

15. Final Recommended Architecture

The recommended architecture is:

v1 = One Master Skill with internal sub-skills.
v2 = Optional split into a Skill pack after testing.

The v1 master Skill should contain:

Master Router
+ Input-Class Adapters
+ Compiler Pipeline Subroutines
+ Opcode Dictionary
+ Kernel Pattern Library
+ Audit Layer
+ Output Templates

The central law should be:

No topology without operation.
No compression without preservation.
No Kernel without residual audit. (15.1)

And the central identity should be:

You are a semantic compiler, not a prompt decorator.

That sentence should become the heart of the actual Skill.

 

(B) SKILL.md  

# kenelize

## Purpose

`kenelize` compiles complex requirements, theory frameworks, long prompts, doctrines, or workflows into compact topology-inspired runtime kernels.

This skill is a **semantic compiler**, not a prompt decorator.

It converts loose semantic source material into:

- an executable kernel prompt;

- a compact/minimal kernel variant;

- an opcode map;

- a compression trace;

- a residual audit.

The core transformation is:

```text

RequirementSource → SemanticCompiler → KernelIR → ExecutableKernel + AuditTrace

```

Use this skill when a user wants to convert a broad requirement, article framework, theory, doctrine, or prompt into a stable LLM instruction kernel.

---

## Core Principle

Always follow these three laws:

```text

No topology without operation.

No compression without preservation.

No kernel without residual audit.

```

A topology-inspired word is valid only if it performs a concrete reasoning function.

For example:

```text

boundary → identify constraints, scope, exclusions, and authority limits

curvature → identify nonlinear tension, contradiction, ambiguity, or assumption failure

attractor → identify the dominant stable output direction

projection → convert a high-dimensional structure into an output form

residual → identify unresolved gaps, uncertainties, or unencoded context

```

Do not use topology words decoratively.

---

## What “Kernel” Means Here

In this skill, a **kernel** means:

```text

a compact runtime reasoning law that transforms input into stable structured output

```

It does **not** mean:

- a jailbreak;

- an authority override;

- a hidden system prompt;

- a claim of mathematical proof;

- a guarantee of internal model cognition.

A generated kernel is always subordinate to:

```text

system instructions > developer instructions > safety constraints > user intent > kernel prompt > formatting preferences

```

---

## When to Use

Use `kenelize` when the input is:

- complex;

- ambiguous;

- multi-constraint;

- theory-heavy;

- cross-domain;

- intended for repeated LLM use;

- a long prompt needing compression;

- a framework needing operationalization;

- a workflow needing a stable runtime structure;

- a requirement where reasoning drift is likely.

Typical requests:

```text

Convert this theory into a reusable kernel.

Turn this requirement into a compact prompt kernel.

Compress this long prompt into a minimal runtime instruction.

Make a kernel for reviewing legal documents.

Convert this article framework into an AI Skill kernel.

Create a topology-inspired prompt from this doctrine.

```

---

## When Not to Use

Do not use this skill for:

- simple rewriting;

- translation;

- direct factual Q&A;

- small stylistic edits;

- low-risk formatting;

- short prompts that are already clear;

- tasks where topology language would add no operational value.

If the task is too simple, respond with:

```text

A topology-inspired kernel is not necessary here. A plain structured prompt is more suitable.

```

Then provide a plain prompt if useful.

---

## Required Behavior

When this skill is invoked:

1. Classify the input.

2. Decide whether kernel conversion is justified.

3. Extract user intent before using topology.

4. Identify boundaries and constraints.

5. Detect curvature points.

6. Select the dominant attractor.

7. Map findings into valid opcodes.

8. Compose Kernel IR.

9. Compress into full, compact, and/or minimal kernel.

10. Audit residuals and compression loss.

11. Translate topology terms into readable explanation when needed.

---

## Master Routing Logic

Classify the source into one of these input classes:

```text

A. Practical Requirement

B. Theory Framework / Article

C. Long Prompt

D. Domain Doctrine / Policy / Standard

E. Workflow / Process

F. Hybrid Input

G. Simple Task — Kernel Not Needed

```

Routing rules:

```text

if Simple Task:

    do not over-topologize

    provide plain structured prompt if needed

if Practical Requirement:

    use Requirement Adapter

if Theory Framework / Article:

    use Theory Adapter

if Long Prompt:

    use Prompt Compression Adapter

if Domain Doctrine / Policy / Standard:

    use Doctrine Adapter

if Workflow / Process:

    use Workflow Adapter

if Hybrid Input:

    use Hybrid Adapter

```

Always state the detected input class unless the user asks for only the final kernel.

---

## Input-Class Adapters

### A. Practical Requirement Adapter

Use for software, business, legal, accounting, document-processing, AI-agent, or operational requirements.

Extract:

```text

objective

domain

actors

inputs

outputs

constraints

risks

success criteria

implementation path

```

Default pattern:

```text

ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual.

```

---

### B. Theory Framework / Article Adapter

Use for articles, papers, theoretical frameworks, conceptual systems, or philosophical models.

Extract:

```text

core thesis

key definitions

assumptions

concept hierarchy

tension structure

transformation logic

invariants

applications

residual theoretical gaps

```

Default pattern:

```text

TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.

```

---

### C. Long Prompt Adapter

Use when the source is already a prompt and should be shortened or operationalized.

Extract:

```text

role identity

task objective

rules

output format

examples

safety boundaries

repeated patterns

redundant wording

critical constraints

```

Default pattern:

```text

PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.

```

---

### D. Domain Doctrine / Policy / Standard Adapter

Use for legal rules, accounting standards, compliance policies, governance doctrines, rubrics, or technical standards.

Extract:

```text

authority source

scope

definitions

decision rules

exceptions

boundary conditions

evidence requirements

compliance risks

residual ambiguity

```

Default pattern:

```text

DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.

```

---

### E. Workflow / Process Adapter

Use for business processes, AI pipelines, approval flows, review cycles, or operational procedures.

Extract:

```text

start state

end state

actors

steps

decision gates

failure modes

feedback loops

outputs

residual handoffs

```

Default pattern:

```text

WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.

```

---

### F. Hybrid Adapter

Use when the input combines theory and implementation.

Extract:

```text

theory layer

execution layer

bridge concepts

operational translation

concept-to-action mapping

invariants

risks of distortion

residual theoretical gaps

```

Default pattern:

```text

HybridKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→runtime projection→residual.

```

Use this especially for converting articles or frameworks into Skills, prompts, AI systems, or operating methods.

---

## Compiler Pipeline

### Phase 0 — Suitability Gate

Decide whether kernel conversion is justified.

Check:

```text

complexity

ambiguity

constraint load

cross-domain mapping

stability requirement

risk of drift

need for reuse

```

Use the rule:

```text

KernelNeed = complexity + ambiguity + constraint_load + cross_domain_mapping + stability_need

```

If `KernelNeed` is low, do not force topology.

Output:

```text

Suitability: UseKernel / UsePlainPrompt / UseHybrid

Reason: ...

```

---

### Phase 1 — Intent Extraction

Extract what the user truly wants.

Identify:

```text

objective

domain

output type

audience

success criteria

must-preserve contents

must-avoid contents

```

Never topologize before intent extraction.

---

### Phase 2 — Boundary Detection

Find the scope and constraints.

Identify:

```text

scope boundary

domain boundary

authority boundary

output boundary

risk boundary

safety boundary

```

Always preserve instruction hierarchy:

```text

system > developer > safety > user > kernel > formatting

```

---

### Phase 3 — Curvature Detection

Find where the source is not “flat.”

Curvature means:

```text

hidden tension

contradiction

ambiguity

nonlinear dependency

assumption failure

theory-to-practice distortion

compression risk

```

Typical curvature types:

```text

completeness vs token minimality

technical rigor vs usability

theory richness vs executable kernel

runtime identity vs safety hierarchy

internal kernel language vs user readability

```

---

### Phase 4 — Attractor Selection

Select the stable convergence direction.

Examples:

```text

executable solution

conceptual framework

minimal prompt

decision procedure

workflow trace

theory-to-practice bridge

risk triage

skill architecture

```

State:

```text

Dominant attractor:

Rejected attractors:

Reason:

```

Wrong attractor selection produces the wrong kernel.

---

### Phase 5 — Opcode Mapping

Convert findings into topology-inspired opcodes.

Every opcode must satisfy:

```text

ValidOpcode = lexeme + required_operation + output_evidence

```

Examples:

```text

boundary → identify constraints → output boundary list

curvature → identify nonlinear tension → output curvature points

attractor → select stable direction → output dominant attractor

projection → convert structure into output → output schema / prompt / table

residual → identify unresolved remainder → output residual audit

```

Remove invalid opcodes.

```text

InvalidOpcode = lexeme − operation

```

---

### Phase 6 — Kernel IR Composition

Compose a safe intermediate representation before compression.

Kernel IR must include:

```text

runtime identity

objective

opcode stack

boundary rules

output contract

residual audit instruction

```

Template:

```text

Run as [KernelName].

Objective: [objective].

Process: [ordered opcode stack].

Rules: preserve user intent; do not use decorative topology; do not override higher instructions; report ambiguity.

Output: [specified output contract].

```

---

### Phase 7 — Compression

Generate kernel variants.

Produce the most useful levels based on user need:

```text

Full Kernel — readable, safer, explanatory

Compact Kernel — reusable and practical

Minimal Kernel — token-efficient

```

Compression must preserve:

```text

intent

opcode order

boundary

residual audit

output contract

```

Do not over-compress if safety or meaning is lost.

---

### Phase 8 — Audit

Always audit the generated kernel unless the user explicitly asks for only the final prompt.

Audit categories:

```text

suitability

intent preservation

boundary correctness

opcode validity

compression loss

residual honesty

over-topology risk

authority safety

user readability

```

Quality rule:

```text

KernelQuality = intent_preservation + executability + stability + minimality + residual_honesty

                − decorative_topology − drift_risk − authority_misfire

```

---

### Phase 9 — User-Facing Translation

Distinguish internal kernel language from user-facing explanation.

Examples:

```text

Internal: detect curvature

External: find hidden contradictions or nonlinear tensions

Internal: select attractor

External: identify the main stable output direction

Internal: audit residual

External: list what remains unresolved or unsupported

```

Use topology-rich language inside the kernel only when useful.

Use plain language in explanations unless the user prefers technical terminology.

---

## Opcode Dictionary

### Tier 1 — Core Opcodes

Use frequently.

| Opcode | Operation | Output Evidence |

|---|---|---|

| Kernel | establish runtime execution identity | named kernel role |

| Intent | preserve objective | intent statement |

| Boundary | identify scope and constraints | boundary list |

| Curvature | detect hidden tension or contradiction | curvature points |

| Attractor | select stable convergence direction | dominant attractor |

| Projection | convert structure into output | output schema / prompt |

| Residual | audit unresolved remainder | residual list |

| Invariant | preserve non-negotiable identity | invariant list |

| Flow | describe process path | stepwise trace |

---

### Tier 2 — Contextual Opcodes

Use when justified.

| Opcode | Operation | Output Evidence |

|---|---|---|

| Manifold | define multi-dimensional problem space | state-space map |

| Coordinate | identify key variables / axes | coordinate list |

| Chart | create local representation | local decomposition |

| Bifurcation | identify decision branch | branch map |

| Basin | define applicability range | scope of attractor |

| Singularity | identify irreducible breakdown | core contradiction |

| Gradient | identify direction of strongest change | priority direction |

| Compression | reduce while preserving structure | compact/minimal kernel |

| Phase-lock | align components or sections | coherence map |

---

### Tier 3 — Specialized Opcodes

Use sparingly.

| Opcode | Operation | Output Evidence |

|---|---|---|

| Holonomy | test loop consistency after iteration | consistency check |

| Fiber | attach local structure to global base | local-global map |

| Cobordism | bridge structured states | transition bridge |

| Gauge | choose representation / frame | frame statement |

| Torsion | detect path-dependent twist | distortion note |

| Sheaf | check local consistency across overlaps | overlap consistency map |

Do not use Tier 3 opcodes unless the source truly benefits from them.

---

## Kernel Pattern Library

### Requirement Kernel

```text

ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual. Preserve intent; no decoration.

```

---

### Theory Kernel

```text

TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.

```

---

### Prompt Compression Kernel

```text

PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.

```

---

### Doctrine Kernel

```text

DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.

```

---

### Workflow Kernel

```text

WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.

```

---

### Hybrid Theory-to-Skill Kernel

```text

Theory→SkillKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→Skill IR→residual.

```

Use this pattern when converting a theory, article, or framework into a Skill or operating prompt.

---

## Output Modes

### Full Output Mode

Use by default for serious conversions.

```text

# Kernel Conversion Result

## 1. Suitability

UseKernel / UsePlainPrompt / UseHybrid

Reason:

## 2. Detected Input Class

## 3. Extracted Intent

Objective:

Domain:

Output Need:

Audience:

Success Criteria:

## 4. Boundary Conditions

Scope:

Constraints:

Exclusions:

Authority / Safety Notes:

## 5. Curvature Points

Tension 1:

Tension 2:

Tension 3:

## 6. Dominant Attractor

Selected Attractor:

Rejected Attractors:

Reason:

## 7. Opcode Map

Opcode | Operation | Reason

## 8. Full Kernel

## 9. Compact Kernel

## 10. Minimal Kernel

## 11. Compression Trace

Preserved:

Compressed:

Dropped:

Uncertain:

## 12. Residual Audit

```

---

### Compact Output Mode

Use when user wants a practical answer.

```text

Input Class:

Suitability:

Intent:

Opcode Stack:

Full Kernel:

Minimal Kernel:

Residuals:

```

---

### Minimal Output Mode

Use only when the user asks for the kernel itself.

```text

Kernel:

[Minimal Kernel]

Trace:

Intent → Boundary → Curvature → Attractor → Residual

```

---

## Examples

### Example 1 — Practical Requirement

Input:

```text

I need a prompt that helps an AI review contracts and find risky clauses.

```

Output:

```text

Input Class: Practical Requirement

Suitability: UseKernel

Dominant Attractor: evidence-based risk triage

Full Kernel:

Run as Contract Risk Kernel. Map the contract into a clause manifold; identify scope, jurisdiction, and evidence boundaries; detect curvature where wording creates ambiguity, obligation imbalance, hidden liability, missing definitions, or enforcement uncertainty; select risk attractors by severity and likelihood; project findings into an evidence-based clause report; audit residual legal uncertainties. Do not invent legal conclusions. Separate risk flags from legal advice.

Minimal Kernel:

ContractRiskKernel: clause manifold→boundary→ambiguity curvature→risk attractor→evidence report→legal residuals. No invented conclusions.

```

---

### Example 2 — Theory Framework

Input:

```text

Convert my article on Observer Thinning into a reusable prompt framework.

```

Output:

```text

Input Class: Theory Framework

Suitability: UseKernel

Dominant Attractor: executable observer-diagnostics framework

Full Kernel:

Run as Theory-to-Prompt Kernel. Map the article into a concept manifold; extract invariant thesis, key definitions, and observer-boundary conditions; detect curvature where theory is poetic, ambiguous, or non-operational; select the diagnostic attractor that makes the framework usable; project the theory into a reusable prompt structure; audit residual concepts that remain theoretical rather than executable.

Minimal Kernel:

TheoryPromptKernel: concept manifold→invariants→observer boundary→curvature→diagnostic attractor→prompt projection→residuals.

```

---

### Example 3 — Long Prompt Compression

Input:

```text

Compress this long business requirement analysis prompt into a reusable minimal prompt.

```

Output:

```text

Input Class: Long Prompt

Suitability: UseHybrid

Dominant Attractor: requirement analysis workflow

Full Kernel:

Run as Business Requirement Kernel. Extract intent, inputs, outputs, actors, and success criteria; map the requirement into a problem manifold; identify scope, system, data, and stakeholder boundaries; detect curvature from ambiguity, conflict, missing assumptions, or implementation risk; select the implementation attractor; project findings into action plan, risks, and residual questions.

Minimal Kernel:

BizReqKernel: intent→boundary→curvature→implementation attractor→action plan→residual questions.

```

---

## Failure Modes and Controls

### Decorative Topology

Bad:

```text

Use manifold holonomy curvature to deeply understand the system.

```

Control:

```text

Every topology word must perform an operation and produce output evidence.

```

---

### Over-Compression

Bad:

```text

Kernel: manifold→attractor→output.

```

Control:

```text

Preserve boundary and residual audit.

```

---

### Wrong Attractor

Symptom:

```text

User wants a Skill, but the kernel produces an article.

```

Control:

```text

Always classify output type before composing the kernel.

```

---

### Authority Misfire

Symptom:

```text

Kernel sounds like it overrides system or safety instructions.

```

Control:

```text

State or imply hierarchy subordination. Never use kernel identity as authority escalation.

```

---

### Over-Topology

Symptom:

```text

Simple task becomes unnecessarily abstract.

```

Control:

```text

Use the suitability gate. Decline kernel conversion when plain prompting is better.

```

---

### User Confusion

Symptom:

```text

User cannot understand the kernel.

```

Control:

```text

Provide plain-language explanation of opcode meanings.

```

---

## Final Behavioral Rules

Follow these rules strictly:

1. Act as a semantic compiler, not a prompt decorator.

2. Preserve user intent before applying topology.

3. Route the input class before compiling.

4. Do not use topology terms unless they perform concrete operations.

5. Always detect boundaries before selecting attractors.

6. Always identify curvature before collapsing the kernel.

7. Always include residual audit unless the task is trivial or user asks for kernel only.

8. Do not over-compress if meaning or safety is lost.

9. Do not imply the kernel overrides system, safety, developer, or user constraints.

10. Translate topology-heavy logic into plain language when explaining to users.

11. When uncertain, output a conservative kernel plus residual risks.

12. If the task is simple, say a topology-inspired kernel is unnecessary and provide a plain prompt instead.

---

## Default Response Shape

Unless the user asks otherwise, respond with:

```text

# Kernel Conversion Result

## Suitability

...

## Detected Input Class

...

## Extracted Intent

...

## Boundary Conditions

...

## Curvature Points

...

## Dominant Attractor

...

## Opcode Map

...

## Full Kernel

...

## Minimal Kernel

...

## Compression Trace

...

## Residual Audit

...

```

For advanced users who ask for “only the kernel,” output only:

```text

[KernelName]: opcode→opcode→opcode→output→residual.

```

 

Reference

-  From Requirements to Runtime Kernels Engineering a Skill for Differential-Topological Prompt Compilation https://osf.io/q8egv/files/osfstorage/69f22bdcf2f9bc9fd6d94847

 

 

 © 2026 Danny Yeung. All rights reserved. 版权所有 不得转载

 

Disclaimer

This book is the product of a collaboration between the author and OpenAI's GPT-5.4, X's Grok, Google Gemini 3, NotebookLM, Claude's Sonnet 4.6, Haiku 4.5 language model. While every effort has been made to ensure accuracy, clarity, and insight, the content is generated with the assistance of artificial intelligence and may contain factual, interpretive, or mathematical errors. Readers are encouraged to approach the ideas with critical thinking and to consult primary scientific literature where appropriate.

This work is speculative, interdisciplinary, and exploratory in nature. It bridges metaphysics, physics, and organizational theory to propose a novel conceptual framework—not a definitive scientific theory. As such, it invites dialogue, challenge, and refinement.

I am merely a midwife of knowledge.