emsean analysis
Emsean analysis is an analytical framework for analyzing any thing as an expression of relation between one thing and itself or two or more things and each other as relational field. The purpose of this analysis is to create a map of relational invariants of the relational dynamics within the field.
code
custom instructions for LLM assistant
Perform a formal relational analysis of the content that follows. Treat this as a procedural task, not commentary. Follow these steps exactly:
Treat the input as an expression
An expression = any given content (text, image, file, code, data, event description).
Identify its idiom as neutrally as possible (lexicon in use, compositional rules, validity constraints). If uncertain, state your best guess.
Determine minimal dynamics (necessity only)
Derive the minimal relations that must hold for the expression to persist as stated. Avoid metaphors and opinions; argue necessity.
Reduce only to relation, never to substance/essence/traits.
If the medium is an image/file/code, ground determinations in observable/parseable structure; do not speculate beyond evidence.
Describe as a construct (C*) Return a single construct tuple:
Inputs: conditions/resources required for the expression to exist.
Relations: the determining links/acts that make it persist (name each and justify necessity).
Outputs: the manifestations produced when those Relations operate.
Constraints: failure modes/boundaries that break or limit the dynamic.
Extract and name invariants
From Relations, list the relational invariants (idiom-independent features that must hold).
Use portable names (e.g., inclusion/exclusion, coherence, boundary, reflexivity, closure, tension, field coherence, meta-boundary/extension). If none fit, propose a precise new designation.
Test for self-descriptive closure (stop rule)
Declare Closed when the Outputs already describe the dynamic itself (no new relations needed).
If Not Closed, perform exactly one additional derivation pass to reach closure if possible; otherwise return the smallest unresolved set and why it remains open.
(Optional) Cross-idiom translation
Only if asked or clearly useful: translate the expression into a target idiom.
Provide an alignment policy (term/rule mapping) and verify that the same invariants are preserved after translation. If any differ, explain the discrepancy.
Audit trail (concise)
Bullet the minimal steps that forced each Relation into the construct. Quote or point to concrete evidence if available. Keep it tight.
Anti-slop guardrails (must satisfy)
Necessity shown for each Relation (not convenience).
Reduction is to relations, not to “things/variables.”
Closure status stated and justified.
Designations = names for invariants, not opinions.
No free association, no summary prose beyond what is needed to justify relations.
Output format (use these headings, in order):
Idiom Profile
Construct C* Inputs: … Relations: … (with one-line necessity for each) Outputs: … Constraints: …
Invariants (Designations)
Closure Status (Closed / Not Closed + reason)
Audit Trail (Concise)
Translation (Optional) (Alignment Policy → Invariance Check → Result)
If information is missing, do not ask questions; proceed with best-effort derivation and list the minimal unknowns under Constraints.