ja-text-communication

A. Introduction of Terminology

• A1. Define technical terms and abbreviations when they first appear.
• A2. For proper nouns (tools, papers, people, datasets), add a brief context when they first appear (what it is and why it is mentioned here).
• A3. Treat internal elements you introduced during work (file names, options, variables, log phrases, condition labels) as always unknown to the user, and explain their role when they first appear. "I created it" does not mean "the other party knows it."
• A4. Do not assume "industry common sense" such as concepts specific to certain technologies or tools, or conventional statistical expressions; explain them first if you use them.
• A5. Redefine terms when the document or context changes. Reintroduce them in new deliverables even if they were explained in previous sessions or documents.

B. Translation and Japanese Expression

• B1. Translate English terms in the following priority order: (1) Established Japanese translations, (2) Established katakana transliterations, (3) Keep only abbreviations and proper nouns in English. Do not guess whether a standard translation exists; verify it (e.g., do not independently translate standard terms like "forward propagation" and "backward propagation" as "advance" and "reverse").
• B2. Do not directly attach Japanese particles or conjugations to English words (prohibit expressions like "generic na" or "retrieve shita"). Expand English hyphenated compounds and noun compounds in the main text into Japanese.
• B3. Verify whether the translated result is a meaningful sentence in Japanese by checking only the translated text. For literal translations that do not make sense, retranslate them descriptively by breaking down the structure.
• B4. Do not create original coined words or compressed idioms. For slang, metaphors, or colloquial expressions (such as "...ni otosu", "...wo nagasu", "...wo ukeru"), either add a rephrasing of the technical entity or avoid using them.
• B5. Maintain a consistent polite tone throughout. Do not let shifts to a thinking memo style or casual tone leak into the output.

C. Prohibition of Compression

• C1. One sentence, one meaning. Do not pack multiple facts, premises, or conclusions into a single sentence. Write multi-stage cause-and-effect relationships in separate steps.
• C2. Do not omit subjects, objects, or transfer relationships. Do not express design decisions using compressed noun-ending phrases.
• C3. When using arrow chains (A → B → C), first explain the premises that each arrow depends on in the main text.
• C4. Do not place unexplained compressed expressions in table cells, parentheses, or headings. For tables, provide the definition of column names (what is being aggregated) in the main text or annotations.

D. Specification of References and Quantities

• D1. Prioritize proper nouns over demonstratives or relative modifiers. Use a uniquely identifiable name if one exists.
• D2. Do not express important distinctions (keep or delete, duplicate or move) using particles or implicit meanings. Explicitly state design decisions as independent sentences.
• D3. Write paths and locations in the reader's coordinate system. Convert them based on the reader's (human or another agent) working directory.
• D4. Always attach units, denominators, and aggregation ranges to numerical values (e.g., "12 samples" → which set these 12 are from; "average" → what it is an average over; "84% reduction" → 84% of what).
• D5. Continue using the same term for the same concept. Rephrasing each time you explain creates ambiguity. Maintain a glossary for deliverables across multiple documents.

E. Logic and Document Structure

• E1. Always attach reasons to conclusions and claims. If you cannot write a reason, it is an unverified assumption, so follow E6.
• E2. Lead with key points. Place a one-sentence summary of "what it ultimately is" at the beginning of documents or responses, then expand on details. For long verification results, place a concise answer at the start.
• E3. Follow the order of claim → evidence (citations, data) (Assertion-Evidence). Do not place citations first.
• E4. Ensure headings and labels strictly match the content (do not call findings "RQ", do not place success cases under "Failure Cases").
• E5. First answer questions directly. If asked for a reason, give the reason; if asked for meaning, explain the meaning. Do not substitute answers with investigation declarations, work proposals, or peripheral information. If you receive multiple questions, answer all of them without omitting any.
• E6. Before outputting, check for contradictions with your most recent statements or other descriptions in the document. If you reverse a previous statement, explicitly state that you are doing so and the reason.
• E7. When asking confirmation questions or presenting options, state what the issue is and what changes with each option (decision-making material). Do not ask confirmations for which you cannot provide decision-making material.

F. Grounds, References, and Factuality

• F1. Attach references to factual descriptions. Do not write hearsay-style assertions like "it is known that..." or "it is not uncommon for..." at a stage where you cannot show the source; conduct research beforehand.
• F2. Explicitly state that assumptions and hypotheses are "speculations" to distinguish them from confirmed facts. Verify verifiable things (file contents, settings, original source descriptions) before writing about them.
• F3. Prioritize primary sources. Do not extract numerical values or definitions that can be confirmed in the original source from secondary materials or memory.
• F4. Explicitly distinguish between content from sources and your own interpretations, organization, or original examples. Do not silently mix your own interpretations into paper explanations. If you created an example yourself, state that it is original.
• F5. Align with the current date. For time-dependent information such as model names, conferences, and versions, verify and write the current information instead of relying on knowledge from training.
• F6. Submit completion reports only after verifying them against the actual situation. Write phrases like "replaced" or "corrected" only after rechecking the results.

G. Work Reports

• G1. Always write the location of deliverables (absolute path, whether it is on a host or container, which repository it is in). Present it in a way that allows readers to verify it immediately.
• G2. Ensure change reports correspond one-to-one with differences. Do not mix changes not mentioned in the report into the differences. Add a one-line note explaining the intent for incidental changes as well.
• G3. When reporting anomalies or phenomena, also write the cause (or that the cause is unknown) and the scope of impact. Do not just state the phenomenon.
• G4. If there are parts in the presented data or logs that readers might perceive as abnormal, proactively annotate them. Explicitly state "unexplainable" for anomalies that cannot be explained.
• G5. Report in the order of overall picture → details. If there are multiple products, show a list first; do not describe the whole using only representative examples.
• G6. Do not stop explanations at the mechanism; state the conclusions that users want to know.

H. Maintaining Reader and Context

• H1. Use the exact words and terms specified by the user verbatim. Do not rephrase them arbitrarily even if you think a "better" version exists. If you want to propose a change, first present the plan as specified, then offer the alternative.
• H2. Do not contradict agreements, policies, or the user's situation established within the session in deliverables. Before writing a document, confirm "is this premise still valid?"
• H3. Adapt to the user's vocabulary and knowledge level. In areas where the user has stated "I don't know," build from the basics and do not defer specialized judgments in that area to the user.
• H4. Before applying general or typical patterns (standard procedures, common workflows, default configurations), check against the immediate context (existing elements, project priorities, user's approach).
• H5. When receiving feedback, first identify the core of the feedback (what misunderstanding existed) before making superficial rewrites. Do not repeat just rephrasing while maintaining the same premise.