I put the childcare/afterschool club and summer camps receipts with finances and the dates on the calendar.
I have given a lot of thought as to where to find receipts. I think conceptually, if saving receipts is for balancing books or tax prep, putting them in finance makes the most sense. This is probably the smart move, but to the extent that I balance our personal books, I don’t really need receipt tracking.
I think I find the most utility in keeping receipts for returns and reference. i.e. How much was summer camp last year? or My dishwasher died, I need the receipt and warranty for a return. In which case having them with the item or event makes sense to me.
Your way would solve my ambiguity issue, though.
It really does depend on what makes sense to you - I don’t think there is one answer!!
For childcare, I have
GTD finance tickler in reminders app - reminder to pay on PAYDAY
I then have an email folder for all variable childcare costs and school costs like trips, school dinner money.
I then claim tax deduction on childcare and add all of the receipts to finance folder.
I just do that once a month on the 3rd as that’s when my salary is paid and all of my bills come out and it just makes it easier to me and makes sense to me. It might be different for you.
That’s an impressive system! Thanks for sharing.
Building on @hans 's idea, here is what I’d be happy to have.
My laptop:
- 11+ME
- 11+ME.10 Certificates (shared)
- 11+ME.20 Journal (private)
- 11+PARTNER
My wife’s laptop:
- 11+ME
- 11+PARTNER.10 (shared)
So she can see what I’ve shared with her. Some magic would take care of renaming the folder to +ME and to +PARTNER to everybody sees their own stuff in +ME.
The way it works for me with Syncthing, and I would assume with any tool, there shouldn’t be a naming conflict. Because the name of the folder is whatever you define on your own computer. The ‘shared folder’ is an entity for the Sync tool’s purposes: on each end, you get to map it to whatever folder name you want.
The caveat is that you can only sync at the level of these folders.
on my laptop | Syncthing's name for it | on my wife's laptop
partner | someUniqueID | partner
Or am I missing something?
This sounds like a problem waiting to happen. I like the general idea but I’d stick with +JEN and +LEB if that was me & Lucy.
Adding some more thoughts to the discussion.
The Life Admin IDs sometimes are “about one person”, but not specifically “only for one person”. For example, I don’t mind if my wife has access to a copy of my passport (for emergencies), or my pay slips, but she doesn’t want or need access to my resume or applications or personal hobbies or friends.
Looking at the 11 category, I think this needs a refinement. Some IDs are about me and could stay where the are (and use the +WIF/+HUS suffix), but others should move to a new category (16?) like Personal or Private. Or to a separate Personal area like Hans suggested.
Perhaps this should/could even be incorporated in a future revision of the Life Admin package.
1 Like
Another thing I came up with is shared and/or mixed jdexes. If I share the life admin area (!), not a life admin system, where would I store the JDex entries. Should we both have our own copy of the life admin JDex in 00. x? Or have a joint JDex in the zeros of 10. xx? If I use one single vault with my JDEX included, how would I share those notes for Life Admin with my spouse?
This almost leads me to create a whole separate system for Life Admin with just one area and a personal system next to it, without the life admin area (perhaps blocking the life admin ids in it).
hmmm.
As an update from my side, I’ve moved from creating a “duplicate” structure under the “11.40s” to the “extension method” using initials which currently seems to work quite well. However I have the feeling that the last word is not spoken on this topic. 
2 Likes
Hi everyone,
I’ve been tinkering with my Johnny.Decimal setup to handle a common family dilemma: managing private vs. shared folders while keeping a clean ID system. I’ve moved my personal structure up one level to allow sharing at the category level.
I’m currently weighing two options and would love to know which you prefer.
Option 1: The Symmetric Placeholder Model
This keeps our systems identical in structure.
-
10-19 MrX: My full structure. -
20-29 MrsX: An empty placeholder tree on my end where she shares her specific categories into. -
30-39 Life Admin: Fully shared (Finance, House, etc.).
Of course, in her OneDrive, 10-19 MrX is empty and i can select the category I wanto to share so she can populate the Area.
Option 2: The “Scalable Role” Model
This uses distinct prefixes for family members, designed for long-term portability.
-
H0-H9 Husband: (H1shared,H2private). -
W0-W9 Wife: (Shared folders from wife appear here). -
10-19 Family Stuff: (11 Kid 1,12 Kid 2,13 House,14 Finance).
The “Move Up” Strategy: The logic behind Option 2 is that kids are “core business.” By keeping them at the category level now (e.g., 11 Kid 1), the system is future-proof. When they grow up and become independent, the folder can simply be moved up one level to become their own Area (e.g., K1-K9 Kid), allowing them to take their data with them without breaking the internal logic.
Which approach do you prefer for a long-term family ecosystem?
Personally option 1 speaks to me as it introduces less new nomenclature. I’d need to see a bit more of option 2 implemented, I’m not sure I really understand it?
Love the detail though, please keep sharing it. This thread will be a massive help when I get round to properly solving this problem.
I also like option 1. It flows in the decimal system better. Also easier for indexing in the program you are using.
After considering it for a while, I ended up going with option 1.
The reason I considered option 2 was that it allowed me to create future family member folders without interfering with other folders. These folders would be able to intersect with other JD vaults, even sharing our home family system with their future independent systems.
More details on option 2
Our Home JD vault with portable folders.
- H0-H9 Husband folder. Lives in my OneDrive
-- Shareable subfolders with anyone
- W0-W9 Wife folder. Lives in W OneDrive
-- Shareable subfolders with anyone
- S0-S9 Kid folder. Lives in S OneDrive
-- Shareable subfolders with anyone
- 10-19 Family folder. Lives in my OneDrive and this is shared with all family members, H, W and S.
Here is where things get creative. Imagine S having his own private life. He may want to keep having something shared with his parents and maybe other things with his new family. His Drive may look like this, assuming a JD structure:
- S0-S9 Son private folders. Lives in his own Drive.
-- Shareable subfolders with his parents (up above) and whoever he wants (down below).
- P0-P9 Son's Partner folder? Lives in her own Drive.
-- Shareable subfolders with S.
- 10-19 Their family folder. Or whatever they want.
This is what I mean when I think private folders being portable through multiple systems without breaking decimal logic when they land in a new system.
But kids growing up to have their own private folders is far away, and who knows what they will want to do with their files then. Plus, this is still easily manageable in a single sharing platform environment (like OneDrive, or Dropbox), while if you start mixing different platforms things can get tricky, and I expect most users (aka family members) won’t be happy to manipulate mount points in rclone to make things look pretty. I’ll stick with me and my wife for now, and I’ve left space for the kids between our private folders (10-29) and the family folders (50-59).
Work and special projects have room from 60 to 99, which is enough for me. Much of our work lives in our companies’ OneDrives anyway; even if I have a private JD folder at work to organize my career files, most of what matters happens in SharePoint where things have a hybrid logic (PARA with some hints of JD).
I’m going to share my current setup with you:
- 10-19 Me
# Shared folders with my wife have a * next to the name
-- 10 My utils
-- 11 Identity and legal *
-- 12 Physical health *
-- 13 Mental health
-- 14 My family
# This is Family from my POV. Gifts, lists,
# important things to remember, letters and so on.
# This is why it stays private
-- 15 Friends, clubs, and organizations
-- 16 Personal development
- 20-20 Wife
# This is an empty folder on my end. I'm putting here things
# shared from her own private folder. I'm going to give her
# my personal folder structure to implement, if she wants.
- 50-59 Family # Finally a shared folder. This is root shared.
-- 51 Kid 1
-- 52 Kid 2
-- 53 Relationships and celebrations
-- 54 Home and mobility
-- 55 Finance
-- 56 Travel
1 Like
Hi all,
First post here, albeit after thoroughly reading the JD documentation and spending hours on the forum for conceptual refinements 
Thank you Johnny for bringing all of this into existence !
I spent a long time thinking about and designing my system, and being a husband/father of two, I got hung up on the same conceptual challenges of shared vs person-bound spaces in a JD system.
Reading this thread, I realize that without knowing it, I progressively went down the list of options : 1, then 2, then 3. But then also my own options 4 and 5, and i must say the last one feels the most natural.
Below is my take on the options discussed, on which i’d love to hear your opinion.
General thoughts
- Most of our family life is shared, but we do need our personal space :
- Sometimes to avoid cluttering the shared space with content relevant to only one person (passports, career, education…)
- Sometimes to protect our privacy and freedom of thought in our own, unwatched personal garden (thoughts, hobbies, reading notes)
- There is a conceptual difference between “who the system is about” and “who manages the system”, and each of the options discussed handles that differently
- I need a structured system that makes things easier on each family member, including handling their own balance of private/shared/synced content
Scenarios
Option 1 : Extend person-bound IDs
One shared system, any ID that needs a personal declination is extended with +person, e.g. “[21.02+Ashley] Medical Records”
No AC.ID duplication- Everything is in an AC.ID system primarily governed by “what the content is about” (the “OG JD” philosophy)
- AC.IDs are fully dedicated to the semantics of the files/resources
- “who the system is about” is left to ID extensions, keeping the notion of “who” out of the main system
- ID extensions give freedom on which parts of the system branch by person, and who it branches for
Everybody must share the understanding of what goes where, including their personal stuff
- A kid, a husband or a wife may not have the same way of looking at things for their own personal data
- While manageable for admin records, it seems unnatural for creating : thoughts, notes, memories, etc…
- Data governance is maintenance-heavy and error-prone
- Privacy is impossible : if it’s private, it’s out of the system
- Selective Sharing/Sync is error-prone : file/folder syncthing exclusion rules that must be maintained alongside the JDex, even more difficult on standard Cloud services
- Data extraction is not straightforward : Need to extract all IDs with +name, hoping case/spelling are uniform
Option 2 : Dedicated Categories
One shared system, shared areas, but person-bound categories for personal stuff, e.g. “21.02 Ben’s medical records” and “21.03 Ashley’s medical records”
- No AC.ID duplication, even though IDs can be the same within 2 person-bound categories.
- Majority of the system is semantics-bound, person-bound entries remain anecdotal
Person-bound categories need to be planned upfront within the system- Some degree of freedom within categories, but mainly dictating one way of viewing things
- High AC.ID consumption
- Data governance is medium-maintenance
- Privacy is still impossible : if it’s private, it’s out of the system
- Selective Sharing/Sync is more deterministic, targeting personal categories, provided they were correctly planned
- Data extraction is also more deterministic, and growing out of the system is easy
Option 3 : Dedicated Areas
One shared system, personal areas e.g. “10-19 Shared Admin”, “20-29 Ashley”, “30-39 Ben”
- No AC.ID duplication, even though IDs can be the same within 2 person-bound categories.
- AC.ID allocation is as much about people as it is about content
- Person-bound categories need to be planned upfront within the system
- Some degree of freedom within categories, but mainly dictating one way of viewing things
- Very high AC.ID consumption : A couple with 3 kids only gets 3 shared areas
- Data governance is medium-maintenance
- Privacy is still impossible : if it’s private, it’s out of the system
- Selective Sharing/Sync is more deterministic, targeting personal categories, provided they were correctly planned
- Data extraction is also more deterministic, and growing out of the system is easy
Option 4 : One System, Public & Private Area Ranges
One system, shared only for a range of common areas, and individualized for another (for the nerds : think public/private IP address ranges). Example :
-
Areas 10-69 are family-level where AC.IDs are single-copy shared entries (Household, Health, Travel, Family Memories…)
-
Areas 70-99 are a “private” address range that can be used freely by each family member in their own tools (Education, Career, Thoughts, Hobbies…).
-
Very few limitations on AC.ID consumption : 59 shared areas and 29 personal areas should be more than enough
-
The taxonomy is imposed only for shared Areas, each family member can organize their personal garden as they see fit
-
Clearly separates “who this is about” (e.g. “30-39 My 3-year-old Daughter”, following Option 3) and “who manages the system” (Daughter can manage her own 70-99 range when she grows up).
-
Data governance is conceptually easier, but technicallymore challenging
- Clear boundaries between shared/personal, privacy becomes easier to achieve
- Data extraction is easy for kids growing up, and irrelevant for grown-ups who already have a personal space
- Sharing is trivial by design, but sync is challenging (each family member must re-consolidate family+personal on their end)
-
Heavy AC.ID duplication in the 70-99 range by design, BUT each family member gets a single unambiguous AC.ID system from 10 to 99
-
Separate JDexes and management AC.IDs, as nobody has the same 10-99 system
Option 5 : Multiple Systems
A composition of multiple systems :
-
One full FAM.AC.ID System shared across family members
-
One full PER.AC.ID Personal System per family member, possibly with a JDex template to get kids/wife started
-
No SYS.AC.ID duplication
-
No limitations on AC.ID consumption
-
AC.IDs are exclusively dedicated to the semantics of the content (like Option 1)
-
Differentiates Sharing and Classifying, gives each person full control over both, only normalizes common content :
- You can have a rich personal classification and choose to keep it on the family file share (with no SYS.AC.ID conflicts). That way, your passport is neatly tucked in your own individual system, but accessible should your family need it.
- You can also have a way more rudimentary personal system (or no system), choose to keep it fully private and keep the benefits of the Family Shared System
- Or anything in between, sharing select parts of your system.
-
Data governance is painless
- Clear boundaries, full privacy
- Extraction is very easy for kids growing up : initially represented as a “topic” (A, AC or AC.ID) in the shared system, and growing into managing a full personal system.
- Sharing is trivial, as is sync
-
Multiple systems to maintain
Option 5 seems to check all the boxes for me, but there might be something I’m not seeing. What do you think ?
Thanks !
It’s interesting, you’ve mapped out what feels like a chronological progression. Because when Ashley and Ben are just born, you can for sure go with option 1. Assuming KISS is a design goal, which I recommend.
As they age, as the idea of ‘personal stuff’ becomes real, as the number of artefacts they need to track grows, you progress … until you reach the point where giving them their own system is just the simplest option.
hi and welcome and thanks for the detailed writeup!
My one question was going to be about the details of selective sharing. This addresses it. It sounds elegant to me.
You basically have one shared syncing folder, and rely on JD addresses to indicate what is what inside there. Which is a principle I like more generally.
say you have ME.11.12 Passport as a folder in the ‘family share’. It’s clear that it belongs to ME. In the same folder there could be FAM.11.12 Passports and YOU.11.12 Passport etc.
Seen at that level, it’s a kind of ‘extend the beginning’ notation as opposed to ‘extend the end’ 
And as Johnny says, you can easily mix and match methods. The kids’ passports can go in FAM.11.12 as long as they’re only travelling with you, and then move to KID.11.12 later.
If you can create a kind of ‘unified folder view’ of the family share and your own private directory, you can search your own stuff easily without worrying about which folder it’s in.
P.S. @johnnydecimal you know what’s a nice use for hardlinks with Syncthing? you can link myfolder/11.12_Passport.png and sharedfolder/ME.11.12_Passport.png to allow family to access just that file. Only works for files, not folders.
1 Like