An example of using Strong Attractors to boost LLM analogical thinking
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:
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:
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:
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:
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:
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:
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:
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:
Classify the input.
Decide whether kernel conversion is justified.
Extract user intent before using topology.
Identify boundaries and constraints.
Detect curvature points.
Select the dominant attractor.
Map findings into valid opcodes.
Compose Kernel IR.
Compress into full, compact, and/or minimal kernel.
Audit residuals and compression loss.
Translate topology terms into readable explanation when needed.
Master Routing Logic
Classify the source into one of these 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 — Kernel Not Needed
Routing rules:
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:
objective
domain
actors
inputs
outputs
constraints
risks
success criteria
implementation path
Default pattern:
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:
core thesis
key definitions
assumptions
concept hierarchy
tension structure
transformation logic
invariants
applications
residual theoretical gaps
Default pattern:
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:
role identity
task objective
rules
output format
examples
safety boundaries
repeated patterns
redundant wording
critical constraints
Default pattern:
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:
authority source
scope
definitions
decision rules
exceptions
boundary conditions
evidence requirements
compliance risks
residual ambiguity
Default pattern:
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:
start state
end state
actors
steps
decision gates
failure modes
feedback loops
outputs
residual handoffs
Default pattern:
WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.
F. 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
Default pattern:
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:
complexity
ambiguity
constraint load
cross-domain mapping
stability requirement
risk of drift
need for reuse
Use the rule:
KernelNeed = complexity + ambiguity + constraint_load + cross_domain_mapping + stability_need
If KernelNeed is low, do not force topology.
Output:
Suitability: UseKernel / UsePlainPrompt / UseHybrid
Reason: ...
Phase 1 — Intent Extraction
Extract what the user truly wants.
Identify:
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:
scope boundary
domain boundary
authority boundary
output boundary
risk boundary
safety boundary
Always preserve instruction hierarchy:
system > developer > safety > user > kernel > formatting
Phase 3 — Curvature Detection
Find where the source is not “flat.”
Curvature means:
hidden tension
contradiction
ambiguity
nonlinear dependency
assumption failure
theory-to-practice distortion
compression risk
Typical curvature types:
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:
executable solution
conceptual framework
minimal prompt
decision procedure
workflow trace
theory-to-practice bridge
risk triage
skill architecture
State:
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:
ValidOpcode = lexeme + required_operation + output_evidence
Examples:
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.
InvalidOpcode = lexeme − operation
Phase 6 — Kernel IR Composition
Compose a safe intermediate representation before compression.
Kernel IR must include:
runtime identity
objective
opcode stack
boundary rules
output contract
residual audit instruction
Template:
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:
Full Kernel — readable, safer, explanatory
Compact Kernel — reusable and practical
Minimal Kernel — token-efficient
Compression must preserve:
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:
suitability
intent preservation
boundary correctness
opcode validity
compression loss
residual honesty
over-topology risk
authority safety
user readability
Quality rule:
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:
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
ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual. Preserve intent; no decoration.
Theory Kernel
TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.
Prompt Compression Kernel
PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.
Doctrine Kernel
DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.
Workflow Kernel
WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.
Hybrid Theory-to-Skill Kernel
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.
# 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.
Input Class:
Suitability:
Intent:
Opcode Stack:
Full Kernel:
Minimal Kernel:
Residuals:
Minimal Output Mode
Use only when the user asks for the kernel itself.
Kernel:
[Minimal Kernel]
Trace:
Intent → Boundary → Curvature → Attractor → Residual
Examples
Example 1 — Practical Requirement
Input:
I need a prompt that helps an AI review contracts and find risky clauses.
Output:
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:
Convert my article on Observer Thinning into a reusable prompt framework.
Output:
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:
Compress this long business requirement analysis prompt into a reusable minimal prompt.
Output:
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:
Use manifold holonomy curvature to deeply understand the system.
Control:
Every topology word must perform an operation and produce output evidence.
Over-Compression
Bad:
Kernel: manifold→attractor→output.
Control:
Preserve boundary and residual audit.
Wrong Attractor
Symptom:
User wants a Skill, but the kernel produces an article.
Control:
Always classify output type before composing the kernel.
Authority Misfire
Symptom:
Kernel sounds like it overrides system or safety instructions.
Control:
State or imply hierarchy subordination. Never use kernel identity as authority escalation.
Over-Topology
Symptom:
Simple task becomes unnecessarily abstract.
Control:
Use the suitability gate. Decline kernel conversion when plain prompting is better.
User Confusion
Symptom:
User cannot understand the kernel.
Control:
Provide plain-language explanation of opcode meanings.
Final Behavioral Rules
Follow these rules strictly:
Act as a semantic compiler, not a prompt decorator.
Preserve user intent before applying topology.
Route the input class before compiling.
Do not use topology terms unless they perform concrete operations.
Always detect boundaries before selecting attractors.
Always identify curvature before collapsing the kernel.
Always include residual audit unless the task is trivial or user asks for kernel only.
Do not over-compress if meaning or safety is lost.
Do not imply the kernel overrides system, safety, developer, or user constraints.
Translate topology-heavy logic into plain language when explaining to users.
When uncertain, output a conservative kernel plus residual risks.
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:
# 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:
[KernelName]: opcode→opcode→opcode→output→residual.
Discussion in the ATmosphere