HELIOS: Spell Out the Structure Instead of Hoping the LLM Gets It

LEVEL 1: [CONTEXT]
General information about the task: size, main patterns, architecture

LEVEL 2: [RELATIONSHIP STRUCTURE] 
An explicit map of "what leads to what"
Format: ELEMENT_A → [ELEMENT_B, ELEMENT_C]

LEVEL 3: [ELEMENT DETAILS]
Details of each element, with references to level 2

LEVEL 4: [SOURCE MATERIAL]
Raw tool output or the full text of the document

+ [CRITICAL RULES]
A list of constraints: what's allowed, what isn't

(Optional) FEEDBACK LOOP
Check the result → return the errors → fix

All levels go into a single prompt. The feedback loop is a separate second request, if needed.

Task: Decide whether to launch a new product. You have a 15-page analytical report with market data, competitors, risks and forecasts. You need a structured decision with a rationale.

Prompt:

Analyze the report and give a recommendation on launching the product.

[CRITICAL RULES]
- Use ONLY facts from the report; don't make up data
- Every relationship between factors must be explicitly traced back to its source in the report
- Don't simplify to the point of losing critical details
- If a conclusion depends on several factors, list ALL of them

[TASK CONTEXT]
Product: an AI assistant for automating HR processes
Target audience: companies with 50-200 employees, US
Horizon: a 12-month decision
Key factors from the report: 8 market trends, 4 competitors, 6 risk categories, 3 development scenarios

[RELATIONSHIP STRUCTURE]
Describe the dependency map:
- Which factors lead to a "launch" decision
- Which factors lead to a "don't launch" decision 
- Which factors create conditions (if X, then account for Y)
Format: FACTOR_A (report p. N) → [CONCLUSION_1, CONCLUSION_2] under condition Z

[FACTOR DETAILS]
For each factor in the relationship structure:
- Section number in the report
- Key figures/facts
- Relationship to other factors

[SOURCE MATERIAL]
{paste the full text of the 15-page report}

Result: The model returns a structured decision with explicit traceability of the logic. First it shows the relationship map: "fact A from section 2 + fact B from section 5 → conclusion X, but only if condition C from section 3 holds". Then a detailed rationale for each branch. Finally, a recommendation that lists all critical dependencies with references to the report's pages.

Without the hierarchical structure, the model would give generic reasoning, might miss relationships between different sections, or mix up facts from different scenarios.

LLMs are bad at seeing structure in flat text. When a fact on page 3 of a 15-page document is linked to a fact on page 12 through a condition on page 8, the model may miss that chain. It generates text sequentially and relies on local context, so global dependencies get blurred. This gets worse with complex structure: the more nesting levels and cross-links, the higher the chance the model "loses the thread".

LLMs are excellent with explicit instructions and maps. If the prompt says "block A leads to blocks B and C", the model uses that as a navigation map. It knows where to look and which relationships are mandatory. Hierarchical prompting amplifies this by separating the levels: context → structure → details → material. The model first builds a high-level mental model, then fills in the details, then checks against the raw material.

Critical rules reduce hallucinations. "Don't invent new relationships" + "use only facts from the document" act as guard rails. Without rules the model may invent a convenient but false dependency. With rules it's forced to stay within the provided structure.

Control levers:

• Number of abstraction levels: for simple tasks you can drop level 1 (context) or level 3 (details) and keep only structure + material. For very complex tasks you can add intermediate levels.

• Relationship format: the current "A → [B, C]" format suits graphs and processes. For hierarchies you can use "A contains [B, C]"; for tables, "ROW_X | COLUMN_Y = value".

• Critical rules: tailor them to your pain point. Model making up data? Add "only facts from the document". Oversimplifying until the meaning is lost? Add "preserve all critical details". Mixing different contexts? Add "don't combine facts from different scenarios without explicitly checking the conditions".

• Feedback loop: for code it's the compiler; for text you can check it yourself and send back "paragraph 3 lost the link to the fact from section A", and the model will fix it while keeping the structure.

{one-sentence task description}

[CRITICAL RULES]
- Use ONLY information from the provided materials
- Every relationship and conclusion must be explicitly traceable to its source
- Don't invent new structural elements; use the map described
- {add task-specific rules}

[CONTEXT]
{brief summary: what it is, size, main patterns, specifics}

[RELATIONSHIP STRUCTURE]
{explicit dependency map}
Format: ELEMENT_A → [ELEMENT_B, ELEMENT_C] under condition X
{for hierarchies: ELEMENT_A contains [ELEMENT_B, ELEMENT_C]}
{for processes: STEP_1 → STEP_2 on success / STEP_3 on error}

[ELEMENT DETAILS]
For each element in the relationship structure:
{specific data, source references, additional context}

[SOURCE MATERIAL]
{full document text / tool output / data}

Task: {a specific statement of what you need}

Placeholders: - {task description}: one sentence on what we're doing - {critical rules}: 3-5 task-specific constraints - {context}: a brief summary: size, patterns, quirks - {relationship structure}: a map in the "A → [B, C]" format or similar - {element details}: details for each element on the map - {source material}: the full text / data - {task}: exactly what you want as output

🚀 Quick start: paste this into the chat:

Here is a hierarchical prompt template from the HELIOS study. 
Adapt it to my task: {your task}. 
Ask me questions to fill in every level.

[paste the template above]

The LLM will ask about your source material and have you describe which relationships matter and which rules are critical, so it can build the structure for your task. It will take the 4-level pattern from the template and fill it with specifics.

Researchers from the University of California, Irvine tested the approach on decompilation: turning machine code back into readable C code. It's reverse engineering: you take a compiled program (a binary) and have to recover its source code.

They used Ghidra (a binary analysis tool) to get: - Pseudocode (approximate C code) - The control flow graph (CFG): which code blocks lead to which - The function call graph - P-Code-level details (an intermediate representation of the instructions)

From these they built a 4-level prompt: 1. Function context (architecture, number of blocks, whether there are loops) 2. CFG map ("block_1 → block_2, block_3") 3. Details of each block (P-Code instructions) 4. Raw pseudocode from Ghidra

They also added critical rules ("don't invent new branches", "use library functions, don't rewrite them").

They tested on 6 architectures (x86_32, x86_64, ARM_32, ARM_64, MIPS_32, MIPS_64) with 4 compiler optimization levels (-O0 to -O3). They used the HumanEval and MBPP benchmarks, tasks with unit tests to check correctness.

Metrics: - Compilability: % of functions that successfully compile back into a .o file - Functional correctness: % of functions that pass the unit tests - Edit similarity: textual closeness to the original code

Compared against: - Text-only prompting (just the pseudocode, no structure) - Fine-tuned models (Nova, LLM4Decompile): specialized LLMs trained on "binary-code" pairs

Results:

Baseline text-only approach on x86_64: - GPT-4.1 Mini: 71.4% compilability, 58.0% correctness - Gemini-2.0: 45.0% compilability, 39.6% correctness - At high optimization (-O3), correctness drops to 47.2% and 26.2%

With HELIOS structure: - GPT-4.1 Mini: 89.6% compilability (+18.2 pp), 58.7% correctness - Gemini-2.0: 85.2% compilability (+40.2 pp), 48.8% correctness (+9.2 pp)

Adding compiler feedback (a second pass with the compiler errors): - GPT-4.1 Mini: 96.5% compilability, 55.9% correctness - Gemini-2.0: 94.9% compilability, 53.2% correctness

Cross-architecture results: on ARM and MIPS the structured approach stayed stable (80-90% compilability), while text-only degraded badly on less common architectures.

The fine-tuned models showed high edit similarity (textual resemblance) but low functional correctness: Nova reached only 2-3% correctness, LLM4Decompile (6.7B) 36.3%.

An ablation study (Table V in the paper) showed each component's contribution: - Base prompt: 45.0% compilability - +CFG Overview: +15.4 pp - +Block Details: +8.6 pp - +Critical Rules: +16.2 pp - Everything combined: 85.2% compilability

The critical rules delivered the biggest jump: the model stopped inventing nonexistent branches and started following the provided structure.

HELIOS principles carry over easily to any structured task:

1. Analyzing complex documents

[CONTEXT]: document type, length, main sections
[STRUCTURE]: map of relationships between sections (section 2 builds on data from section 1)
[DETAILS]: key facts for each section
[MATERIAL]: full text

2. Making business decisions

[CONTEXT]: the essence of the decision, factors, scenarios
[STRUCTURE]: a "factor → conclusion under condition" map
[DETAILS]: data for each factor, with sources
[MATERIAL]: reports, research, metrics

3. Breaking down a process or workflow

[CONTEXT]: the process goal, participants, stages
[STRUCTURE]: "step A → step B on success / step C on error"
[DETAILS]: instructions, criteria, owners for each step
[MATERIAL]: policies, examples

4. Argumentation or debate

[CONTEXT]: the thesis, the sides, the scope of the debate
[STRUCTURE]: "argument A relies on facts [B, C], counterargument D refers to E"
[DETAILS]: fully developed arguments with evidence
[MATERIAL]: original sources, data

The key: describe the relationships explicitly; don't hope the model will spot them in the text by itself.

⚠️ Overhead on simple tasks: If the task is linear with no complex structure, a 4-level prompt is overkill. For "write a short summary of the article" a regular prompt is enough.

⚠️ Requires upfront analysis: To build the relationship map you first have to understand the structure of the material. In an unfamiliar domain that can take time. In the study Ghidra handled it; in real work it's you, or a first LLM pass along the lines of "analyze the structure of the document".

⚠️ Doesn't help when there's no structure: If the source material is a chaotic braindump or a pile of unrelated thoughts, you can't build a relationship map. The method works when structure exists but is implicit.

⚠️ Edit similarity vs correctness: In the study HELIOS produced lower textual similarity to the original than the fine-tuned models (26-28% vs 45-55%) but higher functional correctness. If your goal is reproducing the exact wording, the hierarchical approach may give a looser retelling.

HELIOS: Hierarchical Graph Abstraction for Structure-Aware LLM Decompilation Yonatan Gizachew Achamyeleh, Harsh Thomare, Mohammad Abdullah Al Faruque University of California, Irvine

Ghidra Software Reverse Engineering Framework: https://ghidra-sre.org HumanEval benchmark (Anthropic/OpenAI) MBPP (Mostly Basic Python Problems) benchmark