Problem
The parts of the platform worth showing a prospective customer are behind the admin gate: the Lab, the RFCs product and training. Showing them meant making someone an admin, which gives them every admin action, every account's data and the operator's pages. We need a way to show work in progress to someone outside the company with nothing more than they need, and to know that they agreed to keep it confidential before they saw it.
Proposal
A role, not admin
A new platform role, preview, sits beside investor and sales. Like them it lives with
the identity provider, reaches tokens through the sign-in's consent, and opens doors only
where the edge names it. The edge names it on three site sections: the Lab (/lab/),
training (/training/) and the RFCs product (/rfcs/). It does not open the Lab's drafts,
the investor, sales or pricing rooms, the console's admin area or any admin call. Every other
gate stays as it is: default deny.
Nobody gives preview by hand. A signed agreement gives it, and only to a person who holds no
other role. An admin, an editor or an investor who signs keeps the role they have.
The agreement, in versions
An admin writes the agreement in the console (Admin, NDAs): a title, the text, and the questions asked before signing (company, role, what they want to evaluate; each required or not). A draft can change. Publishing makes it the next version, retires the one before, and fixes its SHA-256 over the title, the text and the questions. The database refuses any change to a published version.
The platform ships one draft, labelled as a draft, with no legal terms in it. The owner replaces it with a lawyer's text before the first invitation; nothing can be sent before a version is published.
Clients: a company or an individual
Every invitation is for a client: the party to the agreement. A client is a company or an individual, any size, with its legal name, its country, a registration or VAT number when the admin has one, and notes only admins see. A company may have several people sign for it; each is invited by their own address.
Someone who signs for a company also gives their role there and confirms they are authorised to sign on its behalf; the signature is refused without both. The signed record names the company as the party and the person as its signatory, with the company's details as they were when it was signed, so a later edit of the client never changes a signed record.
The admin's list of clients shows each one's kind, country, how many people were invited and signed, and the newest version signed; it filters companies and individuals.
Invitation, wizard, signature
An admin invites an address for a client. The invitation is mailed with a link to the console, its token
after # so no server log sees it, and only the token's hash is kept. The link works for one
address, once, for 7 days by default.
The mail goes from the platform's no-reply address, the sender of the sign-in mail. It says who invited them, to what, and for which company when they sign for one; besides the link it carries nothing that needs keeping secret.
The invited person signs in (or makes an account) with that address and goes through three steps: the questions, the agreement in full (read to the end before continuing), then a typed full legal name and a ticked "I agree". The page sends the hash of the text it showed; a signature of any other text is refused. The record keeps the person, the address, the version and its hash, the typed name, the answers and the time. A signature never changes; an admin may only revoke it.
After signing, the browser's sign-in is renewed so the new token carries preview at once.
This is a simple electronic signature in the sense of eIDAS: who signed is known from their verified sign-in, and the record shows what they agreed to and when. Whether that is enough for a given agreement is a question for the owner's lawyer, not for this RFC.
The admin's view
The NDAs page lists the invitations (open, signed, withdrawn, expired) and the signatures.
A signature opens as a record that prints or saves as a PDF: the agreement as signed, the
answers, the typed name, the time and the hash. Revoking ends the preview: the person's role
goes back to viewer when they hold no other unrevoked signature, and their sessions at the
identity provider end, so no refresh token carries the old role; their next page signs them in
again. A role given by hand never comes from here: People refuses preview.
The other party signs too
The agreement is mutual, so InOrbit signs it as well. On a signed record an admin countersigns with their typed full name and title, once; the person who signed cannot countersign their own record, and a revoked signature is not countersigned. The record then shows both parties' signatures with their times.
Only the version in force is signed. An invitation sent for a version that was replaced since is refused at signing; the admin sends a new one.
A diagram is drawn here in the RFCs product; this page does not show diagrams yet.
The document and its PDF
The agreement reads as a document wherever it is shown: the admin's page, the signing wizard and the signer's own copy. It carries the issuer's letterhead (INORBIT d.o.o., OIB, MB and seat), the title, the version and its date, the numbered clauses, and the signature block: the signer's name, title, address and time, and InOrbit's countersignature once made. The same parsed text is drawn on the page and set as a PDF by the platform's PDF engine, the one the CV and the invoices use, so the two never read the text differently; nothing in an agreement can run as markup in either.
The PDF is a real file, made by the service: one per version, blank, for the admin, and one
per signature, the countersigned copy, for the admin and for the person who signed it,
nobody else. A copy is named for the version, the party and the day
(inorbit-nda-v2-<party>-<date>.pdf), and the same copy always renders to the same bytes.
Each download is audited with who and which copy, never what it says. The document's own
labels are bilingual, Croatian first, because the Croatian text prevails; a bilingual
agreement is set one language after the other, as its text orders them, not side by side.
Data and audit
The answers and the typed name are personal data. They are never in a log, a metric label, a
URL or a prompt to a model. Audit lines carry who, what and the outcome (nda.invite,
nda.sign, nda.signature.revoke and the rest), never the text or an answer. No IP address
is stored.
A person's export lists what they signed, with their answers, every invitation sent to their address, signed or not, and a client record that is the person themselves (an individual). Erasing a person deletes their signatures, the invitations to their address and that client record. A company's record stays: it is the company's, not the person's.
Open questions
- Retention against erasure. A signed confidentiality agreement may need to outlive an erasure request, as evidence for a legal claim. Today erasure deletes it. Keeping it after erasure is a decision for the owner and their lawyer.
- The agreement's text. The shipped draft is a placeholder. The owner supplies the text.
- More sections. The console's own admin-only products are not opened to
preview; they call admin-only APIs. Opening one means naming the role at the edge and in that service.
Alternatives considered
- Make the signer an admin. Rejected: an admin can change every account, see every person and run the operator's pages. A preview needs to read three sections.
- A shared password or a secret link to the sections. Rejected: nothing records who saw what or what they agreed to, and a link travels.
- A separate e-signature service. Rejected for now: another vendor holding prospective customers' data, for a simple signature the platform can record itself.
Decision
Open. Built and in use for the first previews; the retention question stays with the owner.
Status log
- 2026-10-05: opened and built. Migration
nda, eleven calls on the accounts service, thepreviewrole at the sign-in and the edge, the console's NDAs page and the signing wizard. - 2026-10-05: clients. Migration
nda_clients: a company or an individual is the party to every invitation and signature; a company's signatory gives their role and confirms their authority; the signed record keeps the party as it was.ListNdaClients,SaveNdaClient. InOrbit's countersignature by an admin, once (CountersignNda). - 2026-10-05: review fixes. The console's gate admits
preview(a signer reached the wizard's last page and was refused); revoking ends the person's sessions, so the role goes at once; giving the preview is safe to repeat and a revocation during it is honoured; People refusespreview; a signed invitation tells anyone but its signer only that it is signed; a replaced version is refused at signing; nobody countersigns their own record; export and erasure cover an individual client and every invitation to the address. - 2026-10-06: the document and its PDF. The agreement is set as a paper document on every
page and as a PDF from the service (
DownloadNdaTemplatePdffor the blank version,DownloadNdaSignaturePdffor a signed copy,ListMyNdaSignaturesfor the signer's own); the print button is gone. - 2026-10-07: Checked: the agreement, clients and countersignature, the review fixes and the PDF (#301, #323, #334, #383) run in accounts at 932c4445 and console-ui at dab02d1a. #421 and #474 are open; retention waits on the owner. Open.
- 2026-10-07: a partner may sign as an individual or for a company, chosen by the admin (owner decision, RFC 0064). The party's kind is recorded on the client, shown with every invitation, and frozen on the signature. The agreement's party block follows the kind in both languages (an individual in their own name; a company by its seat, registration and signatory), with the local identifier's label taken from the country and the line left out when there is none. It lands with the templates of #421, in a pull request stacked on it. A signature freezes the filled text and its hash, so the new block applies only to new signatures; existing ones, including the draft prepared for the first client, keep their text.