Fields, not files: why we share data one field at a time
People are often asked for a whole document when an organisation needs two or three facts from it. Essence makes the named field, not the file, the unit of every share and every consent.
Say you are renting a flat. The letting agent needs three things from you: your name, that you are over 18, and that you have the right to rent. The usual way to prove them is to send a scan of your passport, which also carries your passport number, place of birth, nationality, signature and photograph. The agent asked for three facts and received the whole document.
That gap is what Essence is built around. On our platform, the thing you share is a field, not a file.
Sharing a field instead of a file
A document in an Essence vault can follow a published schema that names its parts: given name, family name, date of birth, document number and so on. A share points at one of those named fields. The letting agent's request becomes a share of three fields, and the passport number is not among them.
That sounds like a detail of data modelling. It changes the choice a person faces. With a file, the choice is all or nothing. With fields, it is what was asked for and no more.
A record of every share
Since our June release, the vault has recorded every shared field as its own entry. Each entry holds:
- which field, from which document;
- who receives it, whether a person or an organisation;
- the level of access;
- when the share expires, if it does;
- when it was revoked, if it was;
- the consent it belongs to.
A share is never "I sent them my passport". It is this field, to this recipient, at this level, until this date, under this consent. When a share ends, the record says when.
Consent at the same level
Sharing a field and agreeing to share it are two halves of one act, so we record them in the same detail. The consent service, in the same June release, stores each consent permission as a list of the named fields it covers, not a single yes for a whole document. Each permission has its own level and its own active flag. When one is revoked, the record keeps when it happened, who did it and why.
Our consent requirements, set in April 2026, go a step further, and we are extending the service so that a person can withdraw one field while keeping the others active.
What we hold
Everything in a vault is held in encrypted form. A document is stored as encrypted content, alongside non-secret details of how it was encrypted. The keys that open it are not part of the record.
Our encryption design, approved in April 2026, sets the rule: data is encrypted before it leaves the person's device, and the server never has the ability to decrypt it. Field-level sharing is designed to work within that rule.
Why sending less matters
Revoking a share ends future access to a field. It cannot undo what has already been read. Once an organisation has seen something, no system anywhere can make it unseen, which is why the protection that counts is sending less in the first place. If an organisation only ever receives three fields, three fields are all there is to worry about.
The organisation gains too. A passport scan it did not need is a liability: it has to be stored, protected, kept for the right period and then destroyed. A confirmed date of birth is less to look after, and easier to justify to a data protection officer and to the person it belongs to.
Because the field sits in the data model rather than in a feature added on top, everything we build next, from verification to reusable checks, inherits that shape. A person is asked a narrower question and gives a narrower answer, with a record of which fields went to whom and for how long. An organisation receives what it needs and none of the rest.
If your organisation asks people for whole documents when it only needs a few facts from them, we would like to talk.
Published 14 July 2026