Evidence records

Evidence is proof of data access — that a source can be reached, and that the data reached is the right data. The source list, the fetch, and what came back.

Evidence in Alchex answers one question, and deliberately only one: can we reach the data, and is it the right data. It does not decide whether the data is acceptable — your controls already do that. So nothing on this surface passes, fails or grades anything. What it gives you instead is a demonstration: the connection opened, the credential was accepted, a real request went out, and here is what came back.

That is what convinces a reader. A green tick is somebody's opinion; the rows the system returned are not.

Where records live

Evidence records live in your team's Governance list, beside documents and registers — there is no separate evidence page to go to. Each row is a link, and everything a record can do happens on the record's own page, because reading a record and editing it are the same page. Old record links, including legacy /data addresses, open that same page.

Each record has a code of its own — the short identifier people quote to each other. It lives in the record's Properties panel, docked on the right and open when the record opens — the same home a document, a register and a risk give their code, with the same panel header and ✕ on all four. Click it to select it, and paste it wherever you are writing. If you have a code and want the record, search for it in Governance.

The panel opens on the same facts every record kind opens on — Code, Owner, Created, Status, in that order, in the same rows, and Status is the record's current state. A fact nobody has set reads as a dash rather than vanishing, so the panel you learn on a document is the panel you can read here. There is no Type row on an evidence record: every evidence record is the same kind of thing — a source that gets fetched — and a row whose answer never varies is a line that costs space and says nothing.

To hand someone the record itself rather than its code, open the ⋯ menu at the top of the record and choose Copy link.

A name, and a source

The name is what the record is called, and it is the only text a record carries: up to 120 characters, and it is what you see in the Governance list, at the top of the record, and inside any chip that cites the record from a document. It is the same limit every other record in the workspace has, because they all share one list and one column.

A record opens as a full page of its own, the way a document does: the trail — Governance / the record's name — runs in a bar across the top, whose right end carries a small group of buttons, one per panel; a panel you open docks on the record's right edge, and the record itself reads in a centered column beside it. (Those buttons stood in a slim column of their own down that edge until August 2026. They moved up into the bar; the panels open where they always did.) The trail answers which record am I in and leads back to the list, and the name is typed exactly where it is read; the code and the record's other identity facts sit in the Properties panel on the right, never in the trail.

Records used to carry a second piece of text as well — a statement, a longer sentence under the name. It is gone. On a record backed by a source it said nothing the name did not: choosing what to fetch filled it in for you by gluing the source and the call together ("File on Google Drive."), and that sentence then became the record's name — so the page asked you for the name twice, and the second answer was written by the app. What the record proves is the source it fetches; what it is called is the name at the top.

Give a record a name when you create it from Governance → New — choose Evidence from the Type dropdown and type the name; the popup asks for nothing else, and prints nothing under the field. Change it later by clicking the name at the top of the record and typing — Enter keeps the new name, Escape puts the old one back. Renaming does not create a new version — the version history is about what the record says, and a rename does not change that. It is recorded in the record's history instead, alongside owner and schedule changes.

A record created straight from a pasted link is named from the link itself, cut at a whole word so it never ends mid-word. That is a starting point, not a decision: rename it to whatever you would look for it under.

Writing a record

One field: "What should this record prove access to?" Everything a record can point at is chosen through it, the same way for every source.

The fastest way is a link. Find the thing where it lives — your drive, your file store, your tracker, whose own search you already know — and copy its link with the Share button every source has. Paste it into the field and you are done: the paste is the fetch. The link already says which source and which thing, so the record resolves it through your own connection and checks it at once — a link that merely exists proves nothing, so what is stored is the reach, not the bookmark. A link from a source you have not connected yet is kept too; the record says exactly what is missing and offers to connect it. A link typed rather than pasted is offered as the first row instead of running by itself, so a half-typed address can never fetch early. Only links a source can actually fetch behave this way — a link to a source whose evidence is lists rather than documents is not pretended into a fetch.

No link? Choose the place, then the thing. The field opens on your sources — every system you could connect, not only the ones you have, because what you have not connected is a real answer to what can be asked. The ones you have connected come first, each showing which account it uses; a system you have not connected says so instead of pretending to be available, and choosing it leads to connecting it.

Picking a source scopes the field to it — the source shows as a small chip, and the menu becomes that source's own world. Its prewritten snapshots — its members, its administrators, its audit log — are listed as rows; a snapshot your connection was not granted is listed and locked with the reason, never hidden. Typing a few words runs the source's own search and its real items come back as rows, each with its identifier shown under its name — names and locations only, never the content of anything, and never further than the connection's own permission reaches. Anything you type or paste — an id, a link someone shared with you — is also offered back as a row, exactly as typed. A snapshot that needs one detail before it can run — which organisation, which group — asks for exactly that, inline, and Enter runs it. A source's raw search call is never offered as a row: searching happens in the field itself, and what you pick is always the real thing the search found — a record proves access to a resource, not to a query. You never choose an API call and you never write a query.

A folder opens. On sources with real folders — a drive, a file store — choosing a folder row steps into it: its contents come back as rows in the same field, files to pick, folders to step into further, and a Back row to retrace. The first row inside is always Use this folder, because a folder is evidence too — the record then proves access to the folder and its listing. Stepping in shows names and locations only, never contents, and never further than the connection's own permission reaches; typing exits the folder and asks a new question. On sources without folders nothing changes — there is simply nothing to step into.

Picking the row is the fetch. There is no button between choosing and fetching: the moment you click a row, the record saves the choice and checks it, and the result appears. The same field stays live afterwards — the record page is its own editor, so clicking the pick simply reopens the menu where you left it. The record also remembers what it reached: every passing check keeps the resource's own name and location (name and place only, never contents), so reopening the record still says what it proves access to — even before the fresh check answers, and even when that check comes back from the just-checked window with nothing new to show.

Which controls it proves something for

You attach a record to a control from the control, not from here. Open the control and cite the record in its note — the / palette's References door — and the attachment is made for you. Remove the citation and it is withdrawn again. There is one act and one place to do it, which is the same rule the control itself follows: a control's evidence lives in its note as reference chips, not in a panel beside it.

This matters, because a control audit only reads evidence attached to that control — a record attached to nothing is proof no audit can consume. So if you made a record and an audit does not see it, the thing to check is whether the control's note actually cites it.

The evidence record page used to carry an Audited by picker for the same job. It is gone: two doors onto one act meant a record could be attached from a page that knew nothing about the control's wording, and it sat above the source picker — asking who should grade the record before the record had anything to fetch.

Which documents cite it

Where anything in your library points a citation at this record, the record page lists those documents under Cited by, each one a link. That is the answer to the question worth asking before you repoint a record at a different source: who is relying on it, and who will need to read the change.

You will only ever see documents you are allowed to open — a document on a team you are not on is left out rather than named. And the list appears only when there is something to show: an absent Cited by means nothing was reported, which is not the same as a promise that nothing cites the record.

Nothing here is edited from this page. A citation is written in a document's text, so it appears and disappears as documents change.

The record's history

History at the top of a record opens as a panel docked on its right edge — and it is the same panel every record kind opens: a document, a risk, a register and an uploaded file show this exact list, with the same header, the same filter and the same Restore. One door, one list: the record's activity with its versions in the same stream, because a version is a marker on the record's own timeline rather than a separate ledger.

The toggle at the top switches between All activity and Saved versions only — the same list read two ways, the second being the audit reading. Each saved version leads with its label — v2 · Current, with your note beside it — and the line above says only what happened; the label is never repeated in the sentence.

Versions is what the record has pointed at. Binding a source adds one, and so does changing it later — newest first, each with the source as it stood at the time, whoever changed it, when, and any note left with the change. The whoever is a person's name; a colleague who has since left the workspace is no longer in the member list, so their version reads under their account identifier instead of vanishing. This is what you read when a document cites the record and you need to know which resource was backing it then.

You can also name a version deliberately. Save version in the panel's header opens a note row right in the panel: type your sentence about why — Quarterly review — still the correct export — and the confirm names the number it will mint, Save v3, never asks for one. The source is not touched; changing the source stays its own act and mints its own version, exactly as before.

Any superseded version can be restored. Choose Restore beside it and the record points at that version's source again — as a new version whose note names the act (Restored v2), never by rewinding the list. The re-bound source is checked immediately, so the record also says what that source answers today. Restoring needs the same Author rights as any other edit, and the current version offers no Restore — there is nothing to return to.

The activity lines are what has happened to the record — renamed, archived, restored, moved to another team, the owner changed, the check schedule changed. Each names the change, who made it and when.

The distinction between a line and a version stays sharp even in one list. A rename or an archive does not change what a record points at, so it never moves the version number: a new number always means somebody moved the source that backs it.

Asking for approval

An evidence record can carry a review — a sign-off on a pinned version by a second person. There is no approval panel and no request button on the record: a review is opened through the server's review verb (see how a review is opened), and while one is pending the record's properties show a status line — In review — requested by …, with Locked while in review beneath it. The lock is real: the record's fields, versions, links and archive state all refuse edits until the review is decided or withdrawn, so the sign-off is on the record as it stands. Automated checks keep running and keep recording their results — a check run is an observation about the record, not an edit of it.

A team admin approves or sends it back on their My Approvals page, where the row carries Approve, Send back and View changes (which says whether the pinned version moved the record's source). You cannot decide your own request — the same separation your documents' reviews enforce.
One request at a time per record.
The ask and the answer both travel. Opening a review tells the team's admins; the decision comes back to whoever asked — see Notifications.
The decision is a permanent record in the record's activity. It is a sign-off on version N by a second person — separate from the record's checks, which keep meaning what they always meant.

Exporting a record as a proof pack

The ⋯ menu also offers Download — the same window every record kind opens (see Exporting), which on an evidence record holds one choice: Proof pack (PDF). One file you can hand to somebody who was not in the room, holding what the record is and everything it has ever asserted:

the record's name and its EVD-… code, so the file names the same record a citation does;
its owner and its check cadence — who is accountable, and how often it is re-checked;
its current source — which connected system, and which resource on it;
its complete version history, newest first: the source each version pointed at, the note left with the change, who made it and when.

That last part is the point of the file. A record on a screen tells you what it is fetching today; a proof pack tells you what it was fetching in March, who changed it, and why — which is the question somebody reviewing your records will actually ask.

What the pack does not contain, on purpose: the checks themselves. No fetch results, no returned fields, no fingerprints over the bytes that were kept. Those hold real data from a connected system, and where that data may travel is a separate decision from "may I read this record" — so the pack stays a record of what was being fetched and its history. The checks stay on the record's own page, where the technical detail and provenance panels open them.

Anyone who can read the record can export it, and the file is named after the record. Names are resolved to people rather than left as internal identifiers; where a person can no longer be resolved, their identifier is printed rather than the line being left blank, because a history with an empty actor column is a history nobody can use.

What a fetch proves

Picking runs the call and keeps what comes back — and from then on the record keeps itself current: opening it shows the last kept result at once and quietly re-checks, so the time beside the green word is when it was really last reached. Every check is retained and fingerprinted, whether a person or the record itself asked for it.

What the record leads with is deliberately short: Reached, when, and the returned rows themselves. The full mechanics sit behind one door — Full proof — which opens the three steps every check walks, in order:

Connection — the connected system answered.
Access — the credential holds the permission this call needs.
Data — the request went out and something came back.

Access is its own step on purpose. Most systems answer an under-permissioned read not with a refusal but with a filtered subset — fewer rows, no error. So "data came back" is not evidence that the right data came back. When the credential is short, Alchex reports the data step as not attempted rather than showing you a partial sample, because a partial sample is the most convincing possible way to be wrong.

Below the steps, Full proof carries what an auditor or IT needs to reproduce the fetch: the exact request, the connection it ran as, what was returned, and the fingerprint over the bytes that were kept.

Changing the pick drops the previous result out of view immediately. A result belongs to the question that produced it, and showing one beside a question it never answered would be exactly the kind of quiet lie this surface exists to prevent.

When a source cannot answer

If the connection is missing the permission the pick needs, the record says so in plain sentences — the connection works, this permission is missing, nothing was fetched — names the permission, and offers the one button this page ever shows: Fix access in Settings. Reconnecting with the missing permission approved heals this record and any other that needs the same call. Nothing is fetched until it can be, and nothing is guessed: a partial answer would look like proof and prove nothing.

One older kind of record stops differently. A record made before this page's redesign could store a search — a typed phrase — instead of a thing. A search names no single resource, so it cannot be proof of access; such a record now says "Pick the resource again" and shows no button at all, because no setting can heal it: open the field above and choose the real thing the record should prove access to. Everything the record was — its name, its history, its citations — stays; only the pick is asked for again, once.

Retiring and deleting a record

A record has the same two removal doors every other record in the workspace has, and they mean different things.

Archive retires it: the record leaves the working list but stays whole — its name, every version of it, and every check that ever ran are still readable, and Restore brings it back into use. Delete removes it for good, along with its record of what it was backing. Delete sits at the bottom of the record's ⋯ menu, in red — the same place every record kind keeps it — and always asks before it acts.

Neither is refused because something cites the record. Being cited is still the reason to prefer Archive, because of what the citing sentence can say afterwards: a chip pointing at an archived record goes red and keeps the record's name, so a reader can see which proof was withdrawn and repoint the sentence, while a chip pointing at a deleted one has nothing left to name and reads as a restricted record. References has the full set of chip states.

Archiving and restoring take author rights on the record's team; deleting takes owner rights — the same two rungs that govern a document or a register, so one role behaves the same way wherever you meet it. See Permissions.

What has happened to the record

Below the record, History lists what has been done to it — the name changing, the owner changing, the check cadence changing, an archive, a restore, a move between teams — newest first, with who did it and when.

It is deliberately not the same list as the record's versions. A version is a change to what the record points at: the source it is fetched from. Everything else is an event and appears only here. That is why renaming a record shows up here and nowhere else — the two were once the same list, which meant a record could gain a version without a word of it changing, and archiving then restoring moved it two versions so a cited "v4" said exactly what "v2" said. Keeping them apart is what makes a version number mean the content.

An entry the app does not have a sentence for is still shown, in plain words, rather than dropped. A history that quietly omits what it did not recognise is worse than no history, because it looks complete.

Citing still creates

Reference a connected system from inside a document and the citation mints the evidence record in that document's team, where it appears in this list — the two orders of work (name the proof first, or discover you need it mid-sentence) both stay real.

The connection itself — connecting or reauthorizing a source system — stays in Settings → Connections.