I’m still very new to this so bear with me!!!
I really like the idea of keeping 00–09 reserved for “system” information.
But I cant grasp the concept of having a JDEX for that Area within the System Info for that area.
Isn’t that just duplication? The JDEX is the JDEX, right? So a JDEX within a JDEX feels like listing the index beneath the entry for the index in the index???
I’m sure I’m missing something very basic here and would love to know exactly what I’ve missed…
ID 00.00 is the ID you would give to your JDex, wherever you might have it. If you have your JDex in, say, Apple Notes or whatever note app came with your phone, you’d keep that folder on your filesystem empty and just consider that app to be 00.00. If you’re using something like Bear or Obsidian, however, where notes are actual text files on your filesystem, you’d store them in the 00.00 folder. (Although you don’t necessarily have to! I think some people prefer to store JDex entries in the actual folders they represent.)
The JDex is meant to be a master record of your entire JD system. Every area, category, and ID that exists must have a JDex entry. And since the JDex has an ID of 00.00, it also has to have an entry within the JDex. It’s not an infinite recursion thing; it’s just an empty note titled 00.00 JDex as a way of saying “hey, this ID is taken”.
Each area and category also has room for a JDex at X0.00. I have not had to create an entirely new JDex for one area (nor do I see why you would want to), but for the customized college area in my JD system, I documented how I designed it in the 20.00 entry in my JDex. One advantage of a JDex entry is that you can document extra notes and info about a specific area, and if you expanded an area like I did, you should write down exactly how you did it in the X0.00 entry.
I get that my explanation might be a bit unclear, so feel free to ask clarifying questions! I and everyone else on this forum are happy to help you out.
But, within “10-19 Life Admin”, for example, we’d have at 10.00 JDex for Life Admin (IAW the standard zeros).
So, isn’t that duplication? (Where we already have the JDEX entries for Life Admin within the (overall) JDEX). The JDEX is the JDEX?
Oh, wait. I think I see what I’m missing (kinda…?)
I thought the JDEX, is the JDEX? That is - the WHOLE JDEX.
And, I thought 00.00 would be the JDEX for (only) the 00-09 System Management Area… (My 00-09 is System Management & Information, with 00 being System Management). But it sounds like you’re saying that the entire JDEX needs to be in 00.00. But the entire JDEX can’t have a location within the JDEX, no? So, the location/ID for the JDEX sits outside of the system (I’m just calling that “JDEX”). 00.00 cannot be the JDEX?
UNLESS - the duplication is intentional, and is to allow you to work within an Area without having to come out of the area (or a category) to get a birds eye view of the area (or the category)?
I think I need to revisit the concepts of The Filesystem and The JDEX. I think I’ve got the concepts reversed! And I think that might be because I’m NOT using a simple text editor for the JDEX. I’m using WorkFlowy, which allows a bunch of other things, including hyperlinks to folders in explorer (but only in the desktop app). So, for my implementation, the “top level” is the JDEX (in WorkFlowy), not the Filesystem… 
I know I’m missing something fundamental, and I appreciate you’re help, sir. 
The point of the JDex is to be a blueprint of your Johnny Decimal system. It contains all the IDs you use and what they correspond to. It can be as simple as a plain text file or as complex as a database (although most people use a notes app). This is really important because Johnny Decimal can be applied in more contexts than just computer folders. I’ve been working on organizing my emails according to Johnny Decimal, and once I have the time, I’m going to go through my pile of disorganized papers and make a Johnny Decimal file cabinet out of them. But the JDex doesn’t contain any of your documents; all it is is a list of IDs.
As for the filesystem, that’s just your computer’s folders with Johnny Decimal applied to them. That’s where your documents are stored. Where the JDex fits in your filesystem is: if you’re using the single plain text file method, or if you’re using an app like Bear or Obsidian where your notes are stored on your computer instead of the cloud, you need to store it someplace. So that’s why XX.00 is set aside specifically for that purpose in every system, area, and category: it’s the very first ID you see, so it makes sense that it should define everything that follows it.
You asked about the 00 category: just like every category and area has standard zeroes, the system has standard zeroes too. 00 holds the same standard zeroes as each area and category, but for the system as a whole. If you want to create a JDex that encompasses everything, you can put it in 00.00. Or, if you like, you can maintain a JDex for each area or each category, and put them in X0.00 or XX.00. Do whatever feels right to you!
This is it, right here.
As soon as I’m comfortable with all of the concepts, and I’m able to create areas and categories that are broad enough to be useful to me, I know I’ll get something nailed down that will be fit for purpose.
I know I’m trying too hard. I just need to relax a little and Pareto it a bit! 
keep asking questions! JD is a system with its own logic, and getting input from other humans is invaluable for forming your mental model that will allow you to use it effectively.
I prefer the 00-09 System Management wherein each Area within is the set of categories that would be laid out for just the system (00), but duplicated. So, for instance, the index of 00.00 rather than having another index in 10.00, I actually have 01.00 with the index, and all of the categories that also exist in 00 are in 01, but for that area. This is repeated for all areas, so management for each area is centralized rather than in the areas. There are pros & cons to that, but after doing both ways, I prefer to keep like processes and procedures rather than just slotting in the next free spot with whatever makes sense. I compare it to the block organization of an HDD versus an SSD. If you have an instant database that can search based on ID, then keeping similar things close together doesn’t make a difference, but if you try to apply this to real-life organizations and locations, it can become hectic. So a little extra planning up front for refining the areas & categories, but I think it is worth it.