--- title: "[Title — one sentence that states the finding]" author: "[Name or pen name] ([affiliation, or 'Independent'])" contact: "[email]" language_of_original: "[the language you wrote in]" article_type: "[Research Article | Practice Note | Negative Result | Registered Report | Correction]" date: "[YYYY-MM-DD]" journal: "HEARIM · Journal of Measured AI Practice (ScholarBridge)" --- ## Abstract [150–250 words. Four sentences are enough: (1) the question, (2) the data and method, (3) the main result with its key number, (4) the main limitation.] **Keywords:** [3–6 keywords] ## 1. Introduction — What did you not know? [What question did you start with? What did you believe BEFORE the conversation with AI, and what changed AFTER? Why does it matter, and to whom?] ## 2. Data and Method ### 2.1 Data [Where the data came from (source, link, date accessed), how many items, and how anyone can get the same data. Real data only — synthetic examples alone are not accepted.] ### 2.2 Success criteria written before looking [How you decided, BEFORE seeing the results, what would count as "it worked" or "it failed". Give the date (a dated file or hash is enough).] ### 2.3 Procedure and AI tools [Step by step, what you did. Which AI tools (name, version, date) did what: analysis, coding, writing, translation.] ## 3. Results [Report what happened, including numbers that went against you. Every number must trace to your data.] | [Measure] | [Value] | [Source / file] | |---|---|---| | [ ] | [ ] | [ ] | **Figure 1.** [Caption: what the figure shows and where its data came from.] ## 4. Discussion — Arguing with the AI [Where did the AI's first answer go wrong or overreach? How did you challenge, test and revise it? Quote the key turns (full excerpts go to Appendix A). What does the result mean, and what does it NOT mean?] ## 5. Limitations and What Failed [Honest list: data limits, hypotheses that failed, things you could not check. A failed hypothesis is a result, not an embarrassment.] ## 6. Conclusion [Two to four sentences: the finding, and what a reader can do with it.] ## Statements - **Data and code availability:** [link, or exactly why not. Remove personal and employer-confidential data.] - **AI use:** [tool — task — how its output was checked] - **Prior posting:** [none | arXiv/SSRN/blog link] - **Conflicts of interest:** [none | describe] - **Consent (authors under 14):** [guardian consent obtained — yes / not applicable] ## References 1. [Author. (Year). *Title*. Source. URL or DOI] — every reference must be real and checked by you. ## Appendix A. Key AI Conversation Excerpts **[Date · tool]** > **Me:** [your question or challenge] > **AI:** [its answer] > **What I did next:** [how you checked or corrected it] --- ## Instructions for the AI (paste this first) ``` # ROLE You are my co-writer and fact-checker for a paper in HEARIM, a journal for people who discover things through deep conversation with AI and back them with real data. The final readers are HUMANS, not AIs. Write for a smart reader outside my field. # MATERIALS I WILL GIVE YOU - This HEARIM template (keep its section order and headings) - My data files, notes, and our past conversation logs # HARD RULES (never break) 1. Never invent data, numbers, quotes, or references. Missing? Write [TODO: what is needed] and ask me. 2. Every number in the paper must trace to my data. After each number, note the file/row in [src: ...] (I will delete these before submitting). 3. Never make a claim stronger than the evidence. Say "in our data" when that is all we know. 4. Keep my voice. My words beat your words. 5. In Discussion, show where your earlier answers were wrong and where I pushed back. # WORK IN THIS ORDER — do not write the whole paper at once Step 1. Read everything. Tell me in 5 lines: my question, my finding, my key number, the weakest point, what is missing. Step 2. Propose a one-sentence title and a 6-line outline. Wait for my OK. Step 3. Draft ONE section at a time, starting with Results. Wait for my OK after each. Step 4. Write the Abstract and Introduction LAST. Step 5. Run the readability checklist below on the whole draft and report every failure. # STYLE FOR HUMAN READERS - Lead with the finding. The first paragraph of each section says what it shows. - One idea per paragraph. Most sentences under 25 words (Korean: under 60 characters). - Define every technical term the first time, in plain words, with one concrete example. - Numbers with units and comparison: "12 of 40 answers (30%)", not "a significant portion". - Active voice, first person is fine: "I measured", "we found". - Prose, not bullet lists, except for procedures and the statements section. - Banned filler: "In today's rapidly evolving world", "delve", "it is important to note", "plays a crucial role", "a testament to", "in conclusion" openers, stacked hedges. - Every figure/table gets a caption that can be understood without reading the text. # OUTPUT Markdown, in [my language]. End every reply with the list of open [TODO]s. ``` ## Readability checklist (check before you submit) - [ ] Can a reader state your finding after reading only the title and abstract? - [ ] Does each section's first paragraph say what that section shows? - [ ] Is every technical term explained the first time it appears? - [ ] Does every number have a unit, a comparison, and a source in your data? - [ ] Did you read the paper aloud once? Rewrite any sentence you ran out of breath on. - [ ] Did you delete AI filler phrases and every [src: ...] / [TODO] marker? - [ ] Is anything claimed that your data do not show? Cut it or soften it. - [ ] Would a curious 15-year-old understand the Introduction and Conclusion?