{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig66iwuhf7h4g7fx5lq3xjsbqp27iiempqhbtz3crbror5kp746xm",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mknoseij2to2"
  },
  "path": "/t/an-example-of-using-strong-attractors-to-boost-llm-analogical-thinking/160279#post_3",
  "publishedAt": "2026-04-29T16:31:32.000Z",
  "site": "https://discuss.huggingface.co",
  "textContent": "# kenelize\n\n## Purpose\n\n`kenelize` compiles complex requirements, theory frameworks, long prompts, doctrines, or workflows into compact topology-inspired runtime kernels.\n\nThis skill is a **semantic compiler** , not a prompt decorator.\n\nIt converts loose semantic source material into:\n\n  * an executable kernel prompt;\n\n  * a compact/minimal kernel variant;\n\n  * an opcode map;\n\n  * a compression trace;\n\n  * a residual audit.\n\n\n\n\nThe core transformation is:\n\n\n    RequirementSource → SemanticCompiler → KernelIR → ExecutableKernel + AuditTrace\n\n\n\nUse this skill when a user wants to convert a broad requirement, article framework, theory, doctrine, or prompt into a stable LLM instruction kernel.\n\n* * *\n\n## Core Principle\n\nAlways follow these three laws:\n\n\n    No topology without operation.\n\n    No compression without preservation.\n\n    No kernel without residual audit.\n\n\n\nA topology-inspired word is valid only if it performs a concrete reasoning function.\n\nFor example:\n\n\n    boundary → identify constraints, scope, exclusions, and authority limits\n\n    curvature → identify nonlinear tension, contradiction, ambiguity, or assumption failure\n\n    attractor → identify the dominant stable output direction\n\n    projection → convert a high-dimensional structure into an output form\n\n    residual → identify unresolved gaps, uncertainties, or unencoded context\n\n\n\nDo not use topology words decoratively.\n\n* * *\n\n## What “Kernel” Means Here\n\nIn this skill, a **kernel** means:\n\n\n    a compact runtime reasoning law that transforms input into stable structured output\n\n\n\nIt does **not** mean:\n\n  * a jailbreak;\n\n  * an authority override;\n\n  * a hidden system prompt;\n\n  * a claim of mathematical proof;\n\n  * a guarantee of internal model cognition.\n\n\n\n\nA generated kernel is always subordinate to:\n\n\n    system instructions > developer instructions > safety constraints > user intent > kernel prompt > formatting preferences\n\n\n\n* * *\n\n## When to Use\n\nUse `kenelize` when the input is:\n\n  * complex;\n\n  * ambiguous;\n\n  * multi-constraint;\n\n  * theory-heavy;\n\n  * cross-domain;\n\n  * intended for repeated LLM use;\n\n  * a long prompt needing compression;\n\n  * a framework needing operationalization;\n\n  * a workflow needing a stable runtime structure;\n\n  * a requirement where reasoning drift is likely.\n\n\n\n\nTypical requests:\n\n\n    Convert this theory into a reusable kernel.\n\n    Turn this requirement into a compact prompt kernel.\n\n    Compress this long prompt into a minimal runtime instruction.\n\n    Make a kernel for reviewing legal documents.\n\n    Convert this article framework into an AI Skill kernel.\n\n    Create a topology-inspired prompt from this doctrine.\n\n\n\n* * *\n\n## When Not to Use\n\nDo not use this skill for:\n\n  * simple rewriting;\n\n  * translation;\n\n  * direct factual Q&A;\n\n  * small stylistic edits;\n\n  * low-risk formatting;\n\n  * short prompts that are already clear;\n\n  * tasks where topology language would add no operational value.\n\n\n\n\nIf the task is too simple, respond with:\n\n\n    A topology-inspired kernel is not necessary here. A plain structured prompt is more suitable.\n\n\n\nThen provide a plain prompt if useful.\n\n* * *\n\n## Required Behavior\n\nWhen this skill is invoked:\n\n  1. Classify the input.\n\n  2. Decide whether kernel conversion is justified.\n\n  3. Extract user intent before using topology.\n\n  4. Identify boundaries and constraints.\n\n  5. Detect curvature points.\n\n  6. Select the dominant attractor.\n\n  7. Map findings into valid opcodes.\n\n  8. Compose Kernel IR.\n\n  9. Compress into full, compact, and/or minimal kernel.\n\n  10. Audit residuals and compression loss.\n\n  11. Translate topology terms into readable explanation when needed.\n\n\n\n\n* * *\n\n## Master Routing Logic\n\nClassify the source into one of these input classes:\n\n\n    A. Practical Requirement\n\n    B. Theory Framework / Article\n\n    C. Long Prompt\n\n    D. Domain Doctrine / Policy / Standard\n\n    E. Workflow / Process\n\n    F. Hybrid Input\n\n    G. Simple Task — Kernel Not Needed\n\n\n\nRouting rules:\n\n\n    if Simple Task:\n\n    do not over-topologize\n\n    provide plain structured prompt if needed\n\n    if Practical Requirement:\n\n    use Requirement Adapter\n\n    if Theory Framework / Article:\n\n    use Theory Adapter\n\n    if Long Prompt:\n\n    use Prompt Compression Adapter\n\n    if Domain Doctrine / Policy / Standard:\n\n    use Doctrine Adapter\n\n    if Workflow / Process:\n\n    use Workflow Adapter\n\n    if Hybrid Input:\n\n    use Hybrid Adapter\n\n\n\nAlways state the detected input class unless the user asks for only the final kernel.\n\n* * *\n\n## Input-Class Adapters\n\n### A. Practical Requirement Adapter\n\nUse for software, business, legal, accounting, document-processing, AI-agent, or operational requirements.\n\nExtract:\n\n\n    objective\n\n    domain\n\n    actors\n\n    inputs\n\n    outputs\n\n    constraints\n\n    risks\n\n    success criteria\n\n    implementation path\n\n\n\nDefault pattern:\n\n\n    ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual.\n\n\n\n* * *\n\n### B. Theory Framework / Article Adapter\n\nUse for articles, papers, theoretical frameworks, conceptual systems, or philosophical models.\n\nExtract:\n\n\n    core thesis\n\n    key definitions\n\n    assumptions\n\n    concept hierarchy\n\n    tension structure\n\n    transformation logic\n\n    invariants\n\n    applications\n\n    residual theoretical gaps\n\n\n\nDefault pattern:\n\n\n    TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.\n\n\n\n* * *\n\n### C. Long Prompt Adapter\n\nUse when the source is already a prompt and should be shortened or operationalized.\n\nExtract:\n\n\n    role identity\n\n    task objective\n\n    rules\n\n    output format\n\n    examples\n\n    safety boundaries\n\n    repeated patterns\n\n    redundant wording\n\n    critical constraints\n\n\n\nDefault pattern:\n\n\n    PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.\n\n\n\n* * *\n\n### D. Domain Doctrine / Policy / Standard Adapter\n\nUse for legal rules, accounting standards, compliance policies, governance doctrines, rubrics, or technical standards.\n\nExtract:\n\n\n    authority source\n\n    scope\n\n    definitions\n\n    decision rules\n\n    exceptions\n\n    boundary conditions\n\n    evidence requirements\n\n    compliance risks\n\n    residual ambiguity\n\n\n\nDefault pattern:\n\n\n    DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.\n\n\n\n* * *\n\n### E. Workflow / Process Adapter\n\nUse for business processes, AI pipelines, approval flows, review cycles, or operational procedures.\n\nExtract:\n\n\n    start state\n\n    end state\n\n    actors\n\n    steps\n\n    decision gates\n\n    failure modes\n\n    feedback loops\n\n    outputs\n\n    residual handoffs\n\n\n\nDefault pattern:\n\n\n    WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.\n\n\n\n* * *\n\n### F. Hybrid Adapter\n\nUse when the input combines theory and implementation.\n\nExtract:\n\n\n    theory layer\n\n    execution layer\n\n    bridge concepts\n\n    operational translation\n\n    concept-to-action mapping\n\n    invariants\n\n    risks of distortion\n\n    residual theoretical gaps\n\n\n\nDefault pattern:\n\n\n    HybridKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→runtime projection→residual.\n\n\n\nUse this especially for converting articles or frameworks into Skills, prompts, AI systems, or operating methods.\n\n* * *\n\n## Compiler Pipeline\n\n### Phase 0 — Suitability Gate\n\nDecide whether kernel conversion is justified.\n\nCheck:\n\n\n    complexity\n\n    ambiguity\n\n    constraint load\n\n    cross-domain mapping\n\n    stability requirement\n\n    risk of drift\n\n    need for reuse\n\n\n\nUse the rule:\n\n\n    KernelNeed = complexity + ambiguity + constraint_load + cross_domain_mapping + stability_need\n\n\n\nIf `KernelNeed` is low, do not force topology.\n\nOutput:\n\n\n    Suitability: UseKernel / UsePlainPrompt / UseHybrid\n\n    Reason: ...\n\n\n\n* * *\n\n### Phase 1 — Intent Extraction\n\nExtract what the user truly wants.\n\nIdentify:\n\n\n    objective\n\n    domain\n\n    output type\n\n    audience\n\n    success criteria\n\n    must-preserve contents\n\n    must-avoid contents\n\n\n\nNever topologize before intent extraction.\n\n* * *\n\n### Phase 2 — Boundary Detection\n\nFind the scope and constraints.\n\nIdentify:\n\n\n    scope boundary\n\n    domain boundary\n\n    authority boundary\n\n    output boundary\n\n    risk boundary\n\n    safety boundary\n\n\n\nAlways preserve instruction hierarchy:\n\n\n    system > developer > safety > user > kernel > formatting\n\n\n\n* * *\n\n### Phase 3 — Curvature Detection\n\nFind where the source is not “flat.”\n\nCurvature means:\n\n\n    hidden tension\n\n    contradiction\n\n    ambiguity\n\n    nonlinear dependency\n\n    assumption failure\n\n    theory-to-practice distortion\n\n    compression risk\n\n\n\nTypical curvature types:\n\n\n    completeness vs token minimality\n\n    technical rigor vs usability\n\n    theory richness vs executable kernel\n\n    runtime identity vs safety hierarchy\n\n    internal kernel language vs user readability\n\n\n\n* * *\n\n### Phase 4 — Attractor Selection\n\nSelect the stable convergence direction.\n\nExamples:\n\n\n    executable solution\n\n    conceptual framework\n\n    minimal prompt\n\n    decision procedure\n\n    workflow trace\n\n    theory-to-practice bridge\n\n    risk triage\n\n    skill architecture\n\n\n\nState:\n\n\n    Dominant attractor:\n\n    Rejected attractors:\n\n    Reason:\n\n\n\nWrong attractor selection produces the wrong kernel.\n\n* * *\n\n### Phase 5 — Opcode Mapping\n\nConvert findings into topology-inspired opcodes.\n\nEvery opcode must satisfy:\n\n\n    ValidOpcode = lexeme + required_operation + output_evidence\n\n\n\nExamples:\n\n\n    boundary → identify constraints → output boundary list\n\n    curvature → identify nonlinear tension → output curvature points\n\n    attractor → select stable direction → output dominant attractor\n\n    projection → convert structure into output → output schema / prompt / table\n\n    residual → identify unresolved remainder → output residual audit\n\n\n\nRemove invalid opcodes.\n\n\n    InvalidOpcode = lexeme − operation\n\n\n\n* * *\n\n### Phase 6 — Kernel IR Composition\n\nCompose a safe intermediate representation before compression.\n\nKernel IR must include:\n\n\n    runtime identity\n\n    objective\n\n    opcode stack\n\n    boundary rules\n\n    output contract\n\n    residual audit instruction\n\n\n\nTemplate:\n\n\n    Run as [KernelName].\n\n    Objective: [objective].\n\n    Process: [ordered opcode stack].\n\n    Rules: preserve user intent; do not use decorative topology; do not override higher instructions; report ambiguity.\n\n    Output: [specified output contract].\n\n\n\n* * *\n\n### Phase 7 — Compression\n\nGenerate kernel variants.\n\nProduce the most useful levels based on user need:\n\n\n    Full Kernel — readable, safer, explanatory\n\n    Compact Kernel — reusable and practical\n\n    Minimal Kernel — token-efficient\n\n\n\nCompression must preserve:\n\n\n    intent\n\n    opcode order\n\n    boundary\n\n    residual audit\n\n    output contract\n\n\n\nDo not over-compress if safety or meaning is lost.\n\n* * *\n\n### Phase 8 — Audit\n\nAlways audit the generated kernel unless the user explicitly asks for only the final prompt.\n\nAudit categories:\n\n\n    suitability\n\n    intent preservation\n\n    boundary correctness\n\n    opcode validity\n\n    compression loss\n\n    residual honesty\n\n    over-topology risk\n\n    authority safety\n\n    user readability\n\n\n\nQuality rule:\n\n\n    KernelQuality = intent_preservation + executability + stability + minimality + residual_honesty\n\n    − decorative_topology − drift_risk − authority_misfire\n\n\n\n* * *\n\n### Phase 9 — User-Facing Translation\n\nDistinguish internal kernel language from user-facing explanation.\n\nExamples:\n\n\n    Internal: detect curvature\n\n    External: find hidden contradictions or nonlinear tensions\n\n    Internal: select attractor\n\n    External: identify the main stable output direction\n\n    Internal: audit residual\n\n    External: list what remains unresolved or unsupported\n\n\n\nUse topology-rich language inside the kernel only when useful.\n\nUse plain language in explanations unless the user prefers technical terminology.\n\n* * *\n\n## Opcode Dictionary\n\n### Tier 1 — Core Opcodes\n\nUse frequently.\n\n| Opcode | Operation | Output Evidence |\n\n|—|—|—|\n\n| Kernel | establish runtime execution identity | named kernel role |\n\n| Intent | preserve objective | intent statement |\n\n| Boundary | identify scope and constraints | boundary list |\n\n| Curvature | detect hidden tension or contradiction | curvature points |\n\n| Attractor | select stable convergence direction | dominant attractor |\n\n| Projection | convert structure into output | output schema / prompt |\n\n| Residual | audit unresolved remainder | residual list |\n\n| Invariant | preserve non-negotiable identity | invariant list |\n\n| Flow | describe process path | stepwise trace |\n\n* * *\n\n### Tier 2 — Contextual Opcodes\n\nUse when justified.\n\n| Opcode | Operation | Output Evidence |\n\n|—|—|—|\n\n| Manifold | define multi-dimensional problem space | state-space map |\n\n| Coordinate | identify key variables / axes | coordinate list |\n\n| Chart | create local representation | local decomposition |\n\n| Bifurcation | identify decision branch | branch map |\n\n| Basin | define applicability range | scope of attractor |\n\n| Singularity | identify irreducible breakdown | core contradiction |\n\n| Gradient | identify direction of strongest change | priority direction |\n\n| Compression | reduce while preserving structure | compact/minimal kernel |\n\n| Phase-lock | align components or sections | coherence map |\n\n* * *\n\n### Tier 3 — Specialized Opcodes\n\nUse sparingly.\n\n| Opcode | Operation | Output Evidence |\n\n|—|—|—|\n\n| Holonomy | test loop consistency after iteration | consistency check |\n\n| Fiber | attach local structure to global base | local-global map |\n\n| Cobordism | bridge structured states | transition bridge |\n\n| Gauge | choose representation / frame | frame statement |\n\n| Torsion | detect path-dependent twist | distortion note |\n\n| Sheaf | check local consistency across overlaps | overlap consistency map |\n\nDo not use Tier 3 opcodes unless the source truly benefits from them.\n\n* * *\n\n## Kernel Pattern Library\n\n### Requirement Kernel\n\n\n    ReqKernel: intent→manifold→boundary→curvature→attractor→action trace→residual. Preserve intent; no decoration.\n\n\n\n* * *\n\n### Theory Kernel\n\n\n    TheoryKernel: thesis→concept manifold→invariants→curvature→attractor→projection→residual.\n\n\n\n* * *\n\n### Prompt Compression Kernel\n\n\n    PromptKernel: intent→rules→boundary→opcode stack→minimal kernel→loss audit.\n\n\n\n* * *\n\n### Doctrine Kernel\n\n\n    DoctrineKernel: authority→boundary→rule manifold→bifurcation→decision projection→residual.\n\n\n\n* * *\n\n### Workflow Kernel\n\n\n    WorkflowKernel: objective→state manifold→boundary→flow→bifurcation→output trace→residual.\n\n\n\n* * *\n\n### Hybrid Theory-to-Skill Kernel\n\n\n    Theory→SkillKernel: thesis→invariants→execution manifold→boundary→curvature→attractor→Skill IR→residual.\n\n\n\nUse this pattern when converting a theory, article, or framework into a Skill or operating prompt.\n\n* * *\n\n## Output Modes\n\n### Full Output Mode\n\nUse by default for serious conversions.\n\n\n    # Kernel Conversion Result\n\n    ## 1. Suitability\n\n    UseKernel / UsePlainPrompt / UseHybrid\n\n    Reason:\n\n    ## 2. Detected Input Class\n\n    ## 3. Extracted Intent\n\n    Objective:\n\n    Domain:\n\n    Output Need:\n\n    Audience:\n\n    Success Criteria:\n\n    ## 4. Boundary Conditions\n\n    Scope:\n\n    Constraints:\n\n    Exclusions:\n\n    Authority / Safety Notes:\n\n    ## 5. Curvature Points\n\n    Tension 1:\n\n    Tension 2:\n\n    Tension 3:\n\n    ## 6. Dominant Attractor\n\n    Selected Attractor:\n\n    Rejected Attractors:\n\n    Reason:\n\n    ## 7. Opcode Map\n\n    Opcode | Operation | Reason\n\n    ## 8. Full Kernel\n\n    ## 9. Compact Kernel\n\n    ## 10. Minimal Kernel\n\n    ## 11. Compression Trace\n\n    Preserved:\n\n    Compressed:\n\n    Dropped:\n\n    Uncertain:\n\n    ## 12. Residual Audit\n\n\n\n* * *\n\n### Compact Output Mode\n\nUse when user wants a practical answer.\n\n\n    Input Class:\n\n    Suitability:\n\n    Intent:\n\n    Opcode Stack:\n\n    Full Kernel:\n\n    Minimal Kernel:\n\n    Residuals:\n\n\n\n* * *\n\n### Minimal Output Mode\n\nUse only when the user asks for the kernel itself.\n\n\n    Kernel:\n\n    [Minimal Kernel]\n\n    Trace:\n\n    Intent → Boundary → Curvature → Attractor → Residual\n\n\n\n* * *\n\n## Examples\n\n### Example 1 — Practical Requirement\n\nInput:\n\n\n    I need a prompt that helps an AI review contracts and find risky clauses.\n\n\n\nOutput:\n\n\n    Input Class: Practical Requirement\n\n    Suitability: UseKernel\n\n    Dominant Attractor: evidence-based risk triage\n\n    Full Kernel:\n\n    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.\n\n    Minimal Kernel:\n\n    ContractRiskKernel: clause manifold→boundary→ambiguity curvature→risk attractor→evidence report→legal residuals. No invented conclusions.\n\n\n\n* * *\n\n### Example 2 — Theory Framework\n\nInput:\n\n\n    Convert my article on Observer Thinning into a reusable prompt framework.\n\n\n\nOutput:\n\n\n    Input Class: Theory Framework\n\n    Suitability: UseKernel\n\n    Dominant Attractor: executable observer-diagnostics framework\n\n    Full Kernel:\n\n    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.\n\n    Minimal Kernel:\n\n    TheoryPromptKernel: concept manifold→invariants→observer boundary→curvature→diagnostic attractor→prompt projection→residuals.\n\n\n\n* * *\n\n### Example 3 — Long Prompt Compression\n\nInput:\n\n\n    Compress this long business requirement analysis prompt into a reusable minimal prompt.\n\n\n\nOutput:\n\n\n    Input Class: Long Prompt\n\n    Suitability: UseHybrid\n\n    Dominant Attractor: requirement analysis workflow\n\n    Full Kernel:\n\n    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.\n\n    Minimal Kernel:\n\n    BizReqKernel: intent→boundary→curvature→implementation attractor→action plan→residual questions.\n\n\n\n* * *\n\n## Failure Modes and Controls\n\n### Decorative Topology\n\nBad:\n\n\n    Use manifold holonomy curvature to deeply understand the system.\n\n\n\nControl:\n\n\n    Every topology word must perform an operation and produce output evidence.\n\n\n\n* * *\n\n### Over-Compression\n\nBad:\n\n\n    Kernel: manifold→attractor→output.\n\n\n\nControl:\n\n\n    Preserve boundary and residual audit.\n\n\n\n* * *\n\n### Wrong Attractor\n\nSymptom:\n\n\n    User wants a Skill, but the kernel produces an article.\n\n\n\nControl:\n\n\n    Always classify output type before composing the kernel.\n\n\n\n* * *\n\n### Authority Misfire\n\nSymptom:\n\n\n    Kernel sounds like it overrides system or safety instructions.\n\n\n\nControl:\n\n\n    State or imply hierarchy subordination. Never use kernel identity as authority escalation.\n\n\n\n* * *\n\n### Over-Topology\n\nSymptom:\n\n\n    Simple task becomes unnecessarily abstract.\n\n\n\nControl:\n\n\n    Use the suitability gate. Decline kernel conversion when plain prompting is better.\n\n\n\n* * *\n\n### User Confusion\n\nSymptom:\n\n\n    User cannot understand the kernel.\n\n\n\nControl:\n\n\n    Provide plain-language explanation of opcode meanings.\n\n\n\n* * *\n\n## Final Behavioral Rules\n\nFollow these rules strictly:\n\n  1. Act as a semantic compiler, not a prompt decorator.\n\n  2. Preserve user intent before applying topology.\n\n  3. Route the input class before compiling.\n\n  4. Do not use topology terms unless they perform concrete operations.\n\n  5. Always detect boundaries before selecting attractors.\n\n  6. Always identify curvature before collapsing the kernel.\n\n  7. Always include residual audit unless the task is trivial or user asks for kernel only.\n\n  8. Do not over-compress if meaning or safety is lost.\n\n  9. Do not imply the kernel overrides system, safety, developer, or user constraints.\n\n  10. Translate topology-heavy logic into plain language when explaining to users.\n\n  11. When uncertain, output a conservative kernel plus residual risks.\n\n  12. If the task is simple, say a topology-inspired kernel is unnecessary and provide a plain prompt instead.\n\n\n\n\n* * *\n\n## Default Response Shape\n\nUnless the user asks otherwise, respond with:\n\n\n    # Kernel Conversion Result\n\n    ## Suitability\n\n    ...\n\n    ## Detected Input Class\n\n    ...\n\n    ## Extracted Intent\n\n    ...\n\n    ## Boundary Conditions\n\n    ...\n\n    ## Curvature Points\n\n    ...\n\n    ## Dominant Attractor\n\n    ...\n\n    ## Opcode Map\n\n    ...\n\n    ## Full Kernel\n\n    ...\n\n    ## Minimal Kernel\n\n    ...\n\n    ## Compression Trace\n\n    ...\n\n    ## Residual Audit\n\n    ...\n\n\n\nFor advanced users who ask for “only the kernel,” output only:\n\n\n    [KernelName]: opcode→opcode→opcode→output→residual.\n\n",
  "title": "An example of using Strong Attractors to boost LLM analogical thinking"
}