# Why Two Families Should Never Share One Archive

Workspaces are live: a completely separate knowledge base for each family you research, on Professional. They matter for a reason that is not tidiness - researching an unrelated family inside your own archive raises your false-match rate, and conflation is the genealogical error that does the most lasting damage.


Before genealogy software, research lines stayed separate without anyone having to think about it. Your family was a folder. Your husband's family was another folder. The lookup you were doing for a cousin was a third one, probably a shoebox. Nothing in that arrangement invited you to put them together, so nobody did.

Software inverted the default. Almost every tool built since is organised around one tree that everything goes into, and the natural thing to do with a second family is to add it to the first. It is one account, one database, one search box. Keeping two families apart now takes deliberate effort, and the tools rarely explain why you would bother.

Here is why you would bother.

## Conflation is the error that does the most damage

Every research error costs you something, but they are not equal. A wrong date is annoying and self-correcting: the next document contradicts it and you fix it. A missing source is a gap you can go back and fill.

Conflation is different. Conflation is when two different people become one person in your records, usually because they shared a name, roughly a period, and roughly a place. It is the classic serious error in genealogy, and it has two properties that make it worse than everything else.

**It is silent.** A merged pair does not produce a contradiction. It produces a person with a slightly fuller life than either of the originals had: two occupations, a wider span of children, a residence that moved. That does not look like an error. It looks like progress.

**It is inherited.** Every conclusion you reach after the merge is built on the merged person. Their parents become your ancestors. Their siblings become your collateral lines. Six months of subsequent work rests on it, and unwinding it means re-checking all of that work, not just deleting one link.

This is why the proof standard asks for a resolution of conflicting evidence and for reasoned identity arguments rather than name matching. Conflation is the failure the whole methodology is built to prevent.

## Your false-match rate is a property of your pool

Now the part that has nothing to do with how careful you are.

The chance of a false identity match is not only a function of your evidence. It is a function of how many plausible wrong candidates are sitting within reach of the right one. That is a property of the pool you are searching, not of the document in front of you.

Add an unrelated family to your archive and you have not diluted the pool evenly. You have usually added people with the same surnames, from the same region, in the same fifty-year window, because that is why you were asked to research them. You have manufactured a set of collisions that do not exist in the historical record. Two Maria Kowalskis born four years apart in adjacent parishes are a genuinely hard research problem when they are both yours. When one of them belongs to a client, it is a problem you invented.

Automated matching makes this concrete. Systems that suggest duplicates work by grouping people into buckets by name and date signature and then comparing within the bucket, because comparing everyone to everyone does not scale. Those buckets are built out of exactly the things two unrelated families from the same place share. An unrelated family does not sit quietly in a corner of your database. It lands directly in the buckets where your own hardest cases already are.

## Every good feature makes this worse

The uncomfortable version of this argument is that the better your tool is at connecting people, the more it costs you to keep two families in it.

Hints, record suggestions, smart matching, duplicate detection, AI-assisted linking: all of them exist to notice that two records are about the same person, and all of them get more confident as your archive gets denser. That is the correct behaviour. It is why these features are worth having. It also means that a tool with good matching applies more pressure toward a wrong merge than a tool with none, and it applies that pressure hardest at the ambiguous pairs, which is where your contaminated pool put the extra candidates.

We are not exempt from this. KleioBase is built entirely around connection. A name on a witness line in one record is supposed to reach across and attach itself to a person you documented eighteen months ago. The Research Companion answers questions by reading your whole knowledge base. The conflicts page compares every claim against every other claim. All of that is correct inside one family's research and wrong across two, and it is wrong in proportion to how well it works.

## Naming conventions do not fix it

The usual workaround is organisational: a prefix on the surname, a custom tag, a "client" flag, a separate branch of the tree with nobody attached to it.

None of that touches the mechanism. A matcher does not read your tags. A duplicate detector does not respect your naming convention. A search does not know that half these people are notionally in a different project. Everything you added is still in the pool, still in the same buckets, still a candidate. You have labelled the problem rather than removed it.

The only thing that actually works is a boundary drawn below the level where the connecting happens.

## What we built

Workspaces are live today. A workspace is a completely separate knowledge base inside your account: its own records, people, families, places, timeline, conflicts, insights, Tree Health Score, and Research Companion conversations.

Nothing crosses. A duplicate match found in one workspace can never point at a person in another. A research finding in one never appears on the other's list. When you ask the Companion who is missing a death date, it reads the workspace you are in and has no knowledge that the others exist. The boundary is not a filter applied to a shared pool; the pool itself is separate.

A switcher at the top of the sidebar moves you between them. It is a setting on your account rather than something your browser remembers, so it takes effect on every tab and every device at once, and there is no version of this where your laptop and your phone are looking at two different clients.

**Professional includes up to 5 workspaces.** Explorer, Researcher, and Archivist include 1, and every account starts with one default workspace created for it, so nothing changes if you only ever want the one.

Two honest limits. Your monthly credits and Companion budget belong to your account, not to each workspace, so five workspaces draw from one pool: workspaces buy isolation, not extra allowance. And if you later drop below Professional, your extra workspaces become read-only rather than disappearing, which means still fully readable and exportable, indefinitely. The [Workspaces guide](/docs/workspaces) has the exact behaviour, along with how to create, rename, and delete them.

## If you research for clients

Everything above applies with an additional dimension.

A client's family in your archive is not only a contamination risk, it is other people's personal data, some of it about living relatives, sitting in the same place as your own family's. Under the [Data Processing Agreement](/dpa) you are the controller of it and KleioBase is your processor. One workspace per client turns "I am careful about which records belong to whom" into a structural fact you can point at, and it makes the end of an engagement clean: export that client's research, delete that workspace, and nothing you did goes near anyone else's data. [Using KleioBase professionally](/docs/professional-use) covers the rest of that side, including the controls worth changing when a tree includes living people.

## The practice, whatever you use

The feature is ours. The practice is not, and it is worth adopting even if you never open KleioBase.

**Decide the boundary before you start, not after.** The cost of separating two families is trivial on day one and substantial on day two hundred, because by then the merges have already happened and you cannot tell which ones were wrong by looking.

**One archive per research question.** Not per surname, not per client necessarily, but per question you are trying to answer. Your own ancestry is one. A friend's brick wall is another. A speculative line you are testing but do not believe yet is a third, and that third one is the case people most often get wrong, because a speculative branch merged into a proven tree contaminates the proven part rather than the other way round.

**If your tool only gives you one tree, keep the second family out of it entirely.** A separate file, a separate account, a spreadsheet. Anything with a real boundary beats a tag inside a shared pool.

**Export before you experiment.** If you are going to test a risky identity hypothesis, do it somewhere you can throw away.

The instinct behind one big tree is a good one: everything connected, nothing siloed, one place to look. It is the right instinct applied to the wrong unit. Connect everything within a family. Wall off everything between them.

Canonical: https://kleiobase.com/blog/workspaces-keeping-client-research-separate