Inheritance records: use existing categories or keep separate?

10-19 Concepts 14 Build your system
1

Some of my files have to do with my dad’s inheritance who passed away in another country. There are personal documents that I keep under “People” - birth, marriage, death certificates, tax ID, etc. There are documents related to ownership of his apartment, not much different from the papers related to my own house. There are bills and other financial issues related to my dad, not much different from my own financial records. Finally, there is an inventory of his stuff that I have to dispose of, not much different from managing my own belongings. At the same time, I’m hesitant to put these items into my existing categories because everything related to my dad occupies a separate mental space in my brain. I don’t think of his apartment as “place where I live” or of his stuff as “my stuff”.

How would you approach this? Would you create a separate area or place these records in existing categories where possible?

2

This feels like a similar question to the current thread Separate "11 Self" from Life Admin area.

A thought … perhaps from a JDex perspective, just extend the end, e.g. 11.11+Dad.

But those files don’t have to live in your file system, next to your current files. Create a separate folder, populate it only with the IDs you need for your dad’s stuff, and in that JDex entry, just note where it is?

3

That’s what I thought because that’s what I do with many other things. For instance, I have a category 36 Personal Documents with ID 36.11 Birth Certificates with extensions (subdirectories) for all members of my family. Dad’s papers would naturally fall there which is OK. But the last portion of your advice

sounds a little like creating another system and duplicating the existing categories. Not all of them, though - only the relevant ones. But that’s the core of my question. Will keeping Dad’s stuff separate simplify my life or complicate it? I like compartmentalizing areas of my life but at the same time I’ll have to remember that Dad’s letters, for example, are not where I keep all other letters…

Perhaps, my question is more “thinking aloud” than a question - there is no correct answer or rule. But I still appreciate input and thoughts.

4

Oh it’s definitely more complex. So it’s a matter of balancing priorities: are you okay with that, for the trade-off of not having all of his stuff ‘cluttering’ your existing system? Or does it not matter enough?

Maybe you start with his stuff in your system and over time, as you look at it less and less, it gets moved out?

1 Like
5

I’ve been thinking more and more that there’s a place for the good ol’ archive beside the Johnny Decimal System. Or to be precise, it’s not beside the system, because the Index Is the System and it may refer you to all kinds of locations to find the actual files.

I have the following idea for myself, maybe it’s applicable in your situation too: beside my shelves with JD ID stuff is another shelf called ‘archive’. It is a flat line of folders and papers each with a date-based ID, sorted chronologically. As things become less frequently accessed in my working JD files, I move them here and make a note of which ID (ranges) also contain stuff ‘in’ this ID. Thus, I keep my main folders lean, and the less often accessed older stuff is still easily reachable.

Further, your description strikes me as two things mixed up: one is that you want to keep mementos of your dad, the other is the project of wrapping up his estate. That sounds like it deserves its own area, which will hopefully be fairly small and self-contained and temporary. For both things, though, the idea of an archive where things eventually end up might be useful. In both cases, what eventually ends up in your system is the representation of all of this which feels like you own it. For example, you might end up with an ID with your personal memories and souvenirs, and another somewhere else which notes that the business side has been taked care of (with links to the archival IDs …)

For what it’s worth!

6

Technically, AC.09 within each category is reserved for the archive. The top 09 category is also for Archives. But I don’t think that archiving a whole ID or, God forbid, category, is a good idea because you will have gaps in your numbering. It’s OK to have gaps in the numbering but the gaps should be intentional. I need to know that if there is a gap, the number is available. If I archive the whole AC.ID and move it to AC.09, I get duplicate AC.ID codes which is suboptimal.

On the other hand, I do want to get old irrelevant stuff out of sight. So, I decided to avoid creating ID for temporary projects. This is where I put dad’s files:

- 21 People
  - 21.12 Relatives
    - Dad *(memorabilia - journals, letters, photos)*
- 31 Houses and Apartments
  - 31.11 Repairs and Maintenance
    - My House
      - Archive
        - YYYYMMDD some old project
      - YYYYMMDD project 1
      - YYYYMMDD project 2
    - **Dad's apartment
      - YYYYMMDD New locks
      - YYYYMMDD Kitchen remodeling**
  - 31.12 Ownership
     - Archive
       - My old house
     - My House
     - **Dad's apartment**
  - 31.13 Sale
    ...

This way AC.IDs don’t become obsolete and remain active and relevant. Subdirectories may become obsolete. They don’t change the “address” (AC.ID) but may move to the attic (Archive subdirectory). If I sell dad’s apartment, the directory will nicely fit next to my old house in the Archive.

It’s a bit dispersed (files related to dad’s apartment are spread across different AC.ID) but well defined, easy to find, and nicely fits into the existing schema - if I move, I know exactly where to put files for the new home.

Same principle for other Project files - no AC.ID per project. Have AC.ID Projects or AC.ID Project Type and file projects in timestamped folders that can be archived after completion.

For cars, I have

- 32 Cars, Bikes, Scooters
  - 32.11 Purchase
  - 32.12 Repairs and Maintenance
  - 32.13 Registration
  - 32.14 Manuals and How-Tos
  - 32.15 Sale/Disposal

No AC.ID per car because they will become obsolete someday.

Another principle - any subdirectory can have an Archive folder for irrelevant stuff (e.g. Timestamped submitted school essay drafts) with only the latest relevant versions remaining in the subdirectory.

7

100% I do this. It is the correct way to archive individual files.

1 Like
8

My point is that categories and AC.ID folders should not be archived in this way - it will cause gaps in directory structure which may lead to duplicate AC.ID. Therefore, AC.ID folders shall not be created for things that will become irrelevant someday: e.g. a car that I may total or sell, a house that I may sell or move out of. A mortgage that I may refinance. A bank account that I may close. A project that will complete someday.

Also, the number of categories are limited to 10 per area, and the number of ID is limited to 100 per category by design. So, we should avoid having a category for things that we know we will have much fewer than 100 (e.g. family members, cars, or houses) or we know we may have more than 100 (e.g. projects).

This approach may cause creating an extra level of hierarchy but, in the long run, it’s more consistent and sustainable than proliferating AC.ID or underused categories.

E.g. instead of

32 Cars
   32.11 Car 1
   32.12 Car 2

I use the structure I described above, with directories for each car one level deeper.

I know, for things that we may have more than 100, you recommend “extending the end” and modify ID by adding digits or letters. But this leaves the problem with archiving obsolete AC.ID open.

9

There are two ways to think about IDs. And it depends what sort of system you’re running.

There’s the ‘life admin way’. Your system is designed up front, and creating new IDs will happen infrequently. In this case, the approach you have re: cars is the right one.

IDs do a lot more work here. They contain more. They last longer.

And in this scenario, the rule of ‘older IDs group together because they were created together’ probably isn’t so relevant.

But it’s not always possible to do this. You might be at work, and the project is evolving, and you’re using IDs more like individual jobs or tasks. In this case you create new IDs very frequently and each of them probably does less.

And now ‘IDs created together, group together’ is absolutely the case. And this is why I’ve always said that it’s not necessary to archive an ID: just let those old IDs age out with time.

In neither scenario do I (generally) recommend archiving IDs or categories. Of course there will always be exceptions.

1 Like