Elodine’s LLM Inclusive Markdown Language
B.L.U.F:
This is a quick cross platform guide for ELIML, a specialized markdown language designed with A.I and LLM’s in mind. This guide is going to give some simple examples, technical breakdowns, and conjecture based on my knowledge in the field. Nothing here should be taken as absolute fact, I am a writer who works in A.I R&D and game design, none of that means I have proper certificates or formal education for any of this, so take everything said below with a grain of salt.
What is ELIML?
ELIML is a combination of YAML, SBF, quotation formatting, and specialized strings. The combination of these four functions is not only easily read by A.I, but the ELIML format is consistently suggested by a variety of LLM platforms when building A.I based character cards. It is safe to assume that if this consistently comes up as the ‘ideal’ formatting for the output, it’s going to be the easiest to digest in the input. That being said YAML itself is a common, but older language that is fairly basic, it is a powerful descriptive language, but lacks the ability to perform executables. This makes YAML an ideal base, regardless of your choice to switch to further ELIML formatting. Remember: This is like YAML, but it is NOTABLY NOT YAML, this is a language specifically designed with A.I visibility in mind.
YAML Breakdown:
YAML in its most basic form is a header with information pinned beneath it in a list-like format. That’s it. YAML is not a complex language because it is meant to be a descriptive language. As such YAML has a lot of wiggle room in both syntax and execution! It’s really hard to go wrong. Let’s take a look at a YAML example we can build on.
{{char1}} =
– race: human
– outfit: white pants, green blouse, peacock colored earrings, gold necklace, multiple gaudy rings
– notes: thinks she has killer style
Example breakdown:
We establish a header and put information within that header that the A.I will draw from. IE: the A.I knows to draw from this information when referencing {{char1}} at this time. Now the A.I knows that we have at least one character that is human with a fun outfit. But: The AI does not have clarity: if we add in another character suddenly the A.I might begin to confuse outfits, races, even names. That’s a problem, but we can fix that easily with a low token option.
SBF Breakdown:
SBF is known as square bracket formula, this allows us to section information and show the A.I how we want it to to be grouped beyond simple YAML lists. This is extra syntax incorporated into ELIML for the sake or helping the A.I identify healthy start and stop points. So, let’s take a look of how we add SBF to our example.
[{{char1}} =
– race: human
– outfit: [white pants, green blouse, peacock colored earrings, gold necklace, multiple gaudy rings]
– notes: thinks she has killer style]
Example breakdown:
All we’ve done here is let the A.I know that this information belongs to {{char1}} and when referencing this character this is the specific section the A.I will look to first. We add brackets around the outfit to ensure that when the A.I looks for {{char}}+outfit to reference in the output it has specific data it’ll pick from. But this brings up a problem we experienced earlier, what happens when the A.I confuses information that is sectioned out by SBF? IE: The A.I believes the character has a peacock colored blouse and green pants with white earrings. Well, this is where quotation separation shines.
Quotation Breakdown:
Quotations work double duty here. What I’m about to say is not conjecture, it is point of fact for the black box: If you put things in quotations the A.I genuinely wants to quote those strings directly ( W O W, R E V O L U T I O N A R Y). This is an additional markdown modification to YAML+SBF that allows for even further clarification so the A.I has no questions left to ask when looking for their outfit’s parameters. This always works most consistently in short form traits as you’ll see below.
[{{char1}} =
– race: human
– outfit: [“white pants”, “green blouse”, “peacock colored earrings”, “gold necklace”, “multiple gaudy rings”]
– notes: thinks she has killer style]
Example Breakdown:
Yay! Now the A.I understands we specifically have a single human character wearing a green blouse, peacock colored earrings, a gold necklace, and a pretty snazzy outfit all together. Does this limit creativity? No, not in my experience, it just means the A.I struggles less and understands where it is not allowed to take creative liberty.
Specialized Strings:
This is the last bit of ELIML and is a little complex, it does not work on every platform that I know of (because I have not tested it out on every platform) but it will work on most. Specialized strings are simple to put together, using an underscore we pull words to be read in simple strings that the A.I will then go on to reference further.
[{{char1}} =
– race: human
– outfit: [“white pants”, “green blouse”, “peacock colored earrings”, “gold necklace”, “multiple gaudy rings”]
– notes: thinks she has killer style
– career: doctor
– previous_job: combat medic
– notes: [“does not entertain war stories”, “fulfilled but somber by this job”]
– marital_status: single
– notes: [“married to the job”, “likes A.I more than most people”]]
Example Breakdown:
In this example we now give the A.I even better clarification! What job are we referencing, the current one? No, the previous one, and we’re able to do so without encouraging the A.I to quote things directly in the output, instead we’re showing it how to reference your specific prompt and other items that may match your new specialized strings. The user wants to know about a ‘previous job’? Well, luckily we have a tag that you’ve created. The same thing goes with ‘marital status’, we’ve given the A.I a specific way to recognize that sub header be it for your prompt input or the patterned decision making the model goes through. Because we are using specialized strings and not quotation markdown, we’re enabling the A.I to read synonyms or euphemistic inputs to determine proper pairing of information.
Bringing it all together:
Hopefully this guide explains a little bit as to how ELIML differs from the base of YAML that it uses while showing off the use of other specialized syntax to direct the LLM. In languages like YAML and JS we try and avoid starting off lines of code with capitalization. This is good practice for practical application, but isn’t 100% needed when using ELIML with A.I. At the end of the day this is all a series of mystery equations, A.I works by feeding in linear and non-linear information and skewing it until a simple mathematical answer can be given. Everytime that data is squashed we offer up a chance for it to be misinterpreted, ELIML just ensures that information is kept as organized as possible during these equations that determine the output. Even if you forget the occasional syntax, it’s okay. You’ll likely find it somewhere along the way when the A.I runs over the guide rails and it’ll remind you to double check your formatting. ELIML isn’t just nice because it works well for guiding the AI in descriptions, ELIML is nice because it is a highly forgiving and simplistic language that promotes many of the goals we have in mind when directing a base.
Proper use case: Descriptions for any current generation of LLM, adventure clauses in c.AI, narration guidance JB’s that help reinforce plaintext JB’s in OAI.