electronicsignature.software
Ask about early access

Early access · the walls are live, the family path is still fail-closed

The signers are families and minors, so the first question is never the signature. It is whether this adult may sign for this child.

Electronic signature for schools, where the signer is a parent, a guardian, a student or a volunteer — and the document is a permission slip, a media release, an acknowledgement, an IEP consent, a physical or a chaperone agreement. A general-purpose signature tool treats its signer as a counterparty to an agreement. That is the wrong model for a family, and no amount of pricing fixes it.

Ask about early access See the four walls that refuse today →

electronicsignature.software is early access. The guardian wall, the minor wall, the staff wall and the consent gate are wired in front of the capture route and refuse today. What is NOT switched on is the consent substrate that would let a parent through, and the seal provider that would let anything be called executed. Both are named on this page rather than left for a renewal call.

4
guards that fire on a capture, named individually below — and not one more
403
the refusal when the signer has not been proven to speak for the child
422
the refusal a family signature gets today, because consent is not provisioned
0
external signature services, fabricated seals, and records we call executed

The one idea this turns on

A parent signing for a child is not a party signing a contract.

Every general-purpose electronic signature product models the same relationship: two parties, each signing for themselves, each identified well enough that a court would accept it. That model is sound, and it is the wrong shape for a school.

In a school, the person signing is usually not the person the document is about. A guardian signs for a named child. A student may co-sign alongside them. A volunteer signs with no roster relationship to any child at all. The document is not an agreement between equals; it is a permission, a release, an acknowledgement or a consent, attached to a minor who cannot give it themselves.

Which means the first question is not “did this person sign?” It is may this person sign for this child? Get that wrong and you do not have a weak signature. You have a permission slip attributed to an adult with no established relationship to the child on the trip — and you will not discover it until the day it matters.

This is not a gap a cheaper price closes, and it is not a feature that can be added to a signature field. It has to be a wall in front of the write, reading a relationship the school already holds. That is what the third wall below is, and it is the one thing on this page that is fully switched on.

The documents each carry their own retention obligation, too, and they are not the same obligation. A trip slip and a special-education consent do not belong in one undifferentiated pile of signed PDFs, and the difference is not cosmetic — it changes how long the record must be kept and who may ever read it.

How to read every claim below

Five words, kept apart on purpose.

An earlier placement of this product implied that three gates protected a signature when none of the three ran on the signing path. An independent audit caught it. The wording was not invented — every one of those gates exists, is written, is tested and is reachable through an endpoint. They simply were not on the path they were implied to guard.

That failure has one shape: a true sentence with its scope removed. The fix is not a promise to be careful. It is to give each state its own word, print the word on every card, and let a test suite fail the build if a card in one state borrows the vocabulary of another.

Enforced
A registered handler calls it, the handler BRANCHES on what it returns, and the refusal is observable as a status code. This is the only state on this page that means a thing is protecting you today.
Persisted
A registered handler calls it over a row read back out of the append-only evidence ledger — not over something a caller typed into the request.
Advisory
A registered handler calls it over CLIENT-SUPPLIED input, returns a verdict, and stores nothing. It gates no signature. A calculator, not a control — and this page labels every one of them.
Held
The build is finished and the enablement is off: a null provider seam or an unset per-tenant flag. Honest-off, not missing, and not pretend-working.
No caller
Shipped, tested, pure — and nothing in production calls it. Named here rather than counted as a feature.

So when a card below says advisory, it means you can call that endpoint and it will answer correctly — and it is not standing between anyone and a signature. That distinction is the most useful thing on this page.

The capture path

Exactly four guards fire when a signature is captured.

Not three, and not five. They run in this order, each one refusing before anything durable is written, and each one answering a question none of the others can answer. They are listed here with the status code they return, because a guard whose refusal you cannot observe is not a guard you should believe in.

The capture path, in order. 1. Who may bind the institution, refusing with 403. 2. Whether the signer is a minor, refusing with 403. 3. Whether this adult may sign for this child, refusing with 403. 4. Whether the family agreed to transact electronically, refusing with 422. Only after all 4 pass are the four pillars captured and the evidence row written. Every wall is also a card below this figure, with its source file.A CAPTURE REQUEST ENTERS HEREREFUSES1Who may bind the institutionIs this caller staff, if they are claiming to sign AS theschool?4032Whether the signer is a minorIs the person at the keyboard a child?4033Whether this adult may sign for this childHas the relationship between this signer and this childbeen established?4034Whether the family agreed to transact electronicallyDo the four statutory consumer-consent conditions resolveon the server?422Four pillars captured, evidence row written, act auditedAppend-only. Nothing durable is written before this point.
Figure 1 The capture path, drawn from the same four-item list as the cards below it. Each box is one wall, printing its own question and the status code it refuses with; the dashed arrow is the refusal. Nothing durable is written until the last box. Three further guards are built and do NOT run on this path, and they are deliberately absent from this figure rather than drawn in a lighter shade: the section after the cards explains why wiring them is a code change and not a flag.
Wall 1 · refuses with 403Enforced

Who may bind the institution

Is this caller staff, if they are claiming to sign AS the school?

Declaring an institutional signer was the one input that routed around the consumer consent gate entirely, because a business party is outside the consumer ceremony and passes straight through it. That was not a theory: a session holding the role of student posted an institutional signer kind and received a 201, minting a business-party record in the school’s append-only legal ledger. Binding an institution is a staff act, so it now takes a staff role — resolved from one shared predicate with the minor check and the records-access deny set folded in, and fail-closed on a role it does not recognise. The family path is untouched by this wall and stays gated by the consent gate below exactly as before.

apps/api/src/routes/esign.ts:460

Wall 2 · refuses with 403Enforced

Whether the signer is a minor

Is the person at the keyboard a child?

The consent gate below carries an age deny, but its resolver seam is handed only a school and a consent reference: it reads an age off a consent record the caller supplied, never off the caller. So it cannot answer “is the signer a minor?” at all. That is a different question and it needed a different asker. This wall reads the role on the authenticated session through the shipped exhaustive minor predicate — which matters, because a hand-written role === "student" check silently admits a minor who happens to hold a masthead role like senior rep or student playwright. It is mounted before the consent gate deliberately, so it is effective today and is not contingent on the consent substrate ever being provisioned.

apps/api/src/routes/esign.ts:471

Wall 3 · refuses with 403Enforced

Whether this adult may sign for this child

Has the relationship between this signer and this child been established?

This is the wall the category does not have, and it is the reason this product exists. The child’s identifier is stamped onto a durable, append-only evidence row, and it is a plain scalar with no foreign key — so before this wall, the value was any well-formed identifier at all: another family’s child, a child at another school, or nothing that had ever been a child. Neither neighbouring gate could close it. The tenant wall is role-blind: it asks whether the session holds the school, which a student session does. The consent gate has no parameter for which child — it is not that it declines to ask, it cannot ask, by its own type signature. So provisioning the consent substrate would not have added a guardian check; it would have removed the refusal that was the only thing stopping the write. Authorization is not relationship. This wall asks the relationship question against the same guardian predicate the evidence read path, the permission-slip family and the depicted-guardian gate on print orders already use — an enrolled contact record binding this adult to this student, or a verified, unrevoked, unexpired parental claim. It invents no new notion of guardian. A refusal writes nothing, and the unproven identifier is never quietly replaced with a null: that would turn a security fix into an unannounced change to what the ledger records. And the refusal is byte-identical whether the child belongs to another family, another school, or does not exist — so the identifier space cannot be probed through this surface.

apps/api/src/routes/esign-student-coupling-wire.ts, called at esign.ts:484

Wall 4 · refuses with 422Enforced

Whether the family agreed to transact electronically

Do the four statutory consumer-consent conditions resolve on the server?

Federal law gives an electronic signature its effect for a consumer only when a specific consent ceremony holds: affirmative consent, disclosure of what is needed to read the record, a demonstration that the person can actually access it, and no withdrawal — and withdrawal dominates the others. This gate resolves those conditions server-side, never from a client string, and it fails closed. ★ Today it fails closed for every family. The resolver seam is unset, so a consumer consent reference resolves to nothing and the capture is refused. That is stated plainly further down this page, because it is the single most important honest fact about this product: no parent can sign here yet.

apps/api/src/routes/esign-consent-101c-wire.ts, called at esign.ts:501

Then, and only then, the four pillars are captured and bound, the evidence row is written to the append-only ledger, and the act is recorded in the audit log. The tenant is resolved on every route, so row-level isolation and the records-access wall engage on both the write and the read.

What is deliberately not in that list. The refusal catalog for documents that must not be signed electronically, the delivery-path check, and the step-up authentication gate. All three are built. None of the three runs here. The reason is structural rather than a matter of configuration, and the next section is about that, because it is the single easiest thing for a page like this to get wrong.

The structural limit, stated plainly

The capture request has no document-type field. So the refusal catalog cannot gate it.

This is worth being precise about, because “not currently configured” and “cannot” are very different promises, and only one of them is true here.

The body of a capture request carries nine fields: the school, the document identifier, the document bytes, the content type, the wording of the signing act, the signing method, a consent reference, the kind of signer, and the child the signature is coupled to. That is the whole schema.

There is no document-type field. There is no delivery-path field. There is no assurance-level field. So the route never learns whether the thing being signed is a document type that legally must not be signed electronically, never learns which delivery path it arrived by, and never learns what authentication assurance the signer holds.

It follows that wiring any of those three into the capture path is a code change — a schema change, a new server-side resolution step, and new refusal paths with their own tests. It is not a flag someone flips. A page that implied otherwise would be selling a control that does not exist, and would keep passing its own tests while doing it.

Two of the three are worth separating further. The step-up gate is not merely absent from capture; its own endpoint is switched off per tenant and returns a service-unavailable code with the reason attached until a school is named in the flag. And the delivery-path check reads who is authenticated out of the request body, which is the exact inverse of how the capture route builds attribution: there, identity comes off the session on the server and the caller has no field in which to assert it.

We are telling you this on the front door rather than in a footnote, because the version of this page that did not say it was wrong, and it was found out.

Wired to the ledger

What runs over stored evidence, not over request input.

Two append-only ledgers hold the evidence: one for signatures, one for versioned acknowledgements. Every capability below is called by a registered handler over rows read back out of them, and each card names the module the decision lives in and the line the handler calls it from.

Persisted

The four-pillar capture

The four pillars, captured and bound into one record — not four fields in a form

An electronic signature has the legal effect of a wet one only when the capture records four things: that the signer intended to sign this document and not that a keystroke happened; a reference to the resolved consent to transact electronically; the attribution that ties the act to a person; and the association to the exact record signed. The engine captures all four and binds them into a single evidence record, and the validity verdict is fail-closed: a missing pillar reads as pending or invalid, never as a signature with an asterisk. Attribution is the decisive pillar and it is built entirely from server context — the authenticated identity on the session, the request address, the server wall-clock, and a hash computed over the exact bytes the signer submitted. Not one of those four values can be supplied by the caller. That is the difference between an evidence record and a record of what a browser claimed.

packages/shared/src/esign-engine.ts
apps/api/src/routes/esign.ts:545-546, row written :558

Persisted

Acknowledgements, bound to a version

Which version did they actually agree to, and does the old agreement still count?

An acknowledgement that cannot name the version it was given is not evidence of anything. Courts enforce a click-through when the record shows conspicuous notice before the act, an unambiguous affirmative act, and which exact text was on screen — and they decline to enforce a pre-checked box, a passive “by continuing you agree”, or terms merely reachable somewhere on the site. This module refuses those shapes rather than recording them. Acceptances bind the version label and a hash of the version’s content, they are retained append-only so the whole history is provable, and when a document materially changes the old acceptance does not carry forward: the person reads as accepted on the old version only, and a fresh affirmative act is required. This is the mechanism the handbook product’s acknowledgement step uses. Same ledger, no second evidence table, no forked engine.

packages/shared/src/esign-clickwrap.ts
recordAcceptance esign.ts:738; currentlyAccepted :851; requiresReAcceptance :855

Persisted

Attribution completeness

The gaps in an attribution, named one by one — over the stored row

A signature you cannot attribute is not a signature, so the attribution block is checked for completeness across its five decisive facts, and it is checked for whether it binds this document’s bytes rather than some document’s. A hash that does not match is not a warning to be dismissed; it means the attribution does not cover the bytes in front of you. This runs over a record rebuilt from the persisted evidence row, not over request input, and the projection it returns is free of personal data by construction: it emits whether the attribution is complete, how many facts are missing, and whether it binds any document — never the identity, the address, the timestamp or the hash value itself.

packages/shared/src/esign-attribution-engine.ts
esign.ts:898-906 over recordFromEvidenceRow(row)

Persisted

Tamper evidence

Whether the bytes moved after they were sealed — and the honest answer today

A signed record does not become an executed one the instant the pillars are captured. It becomes executable when a seal stands over the signed bytes so any later change is detectable. This layer decides that fail-closed across four states, and the two that matter here are the ones we are actually in and the one we refuse to fake: if the document hash the seal attests no longer matches the current document, the record is rejected as tampered, never quietly treated as executed; and if no seal provider has been provisioned, the record reads valid but unsealed, which is explicitly not executable. That second state is the one every record in this system is in today. It is why the word executed does not appear as a claim anywhere on this page.

packages/shared/src/esign-tamper-seal.ts
verifySeal esign.ts:900, isExecutable :910, batchSealStatus :945 (staff-walled :940)

Persisted

Store eligibility

Whether a record is even eligible to be kept as an executed record

Retention is a legal obligation with a shape: the record must be kept, retrievable, and able to accurately reproduce what was signed. The eligibility check runs over the persisted evidence record and answers whether it qualifies to enter a long-term executed-record store at all — and because nothing is sealed today, the honest answer it returns is that nothing yet does. ★ Note the boundary carefully, because it is the kind of thing a page like this usually blurs: eligibility is computed over the stored row, but the retention status endpoint further down grades booleans the caller sends. Those are different layers and this page keeps them apart.

packages/shared/src/esign-executed-record-store.ts
isEligibleForStore esign.ts:914

Correct, callable, and not protecting you

The endpoints that answer a question and gate nothing.

Each of these is real, wired, and returns a sound verdict. Each one runs over input the caller supplied, stores nothing, and stands between no one and a signature. They are genuinely useful — an operator can ask where a document type must be routed, or which condition a consent ceremony fails — and describing them as protections would be false.

Advisory · persists nothing

Carve-out signing path

POST /v1/esign/signing-path

Resolves whether a document type may be signed electronically at all, and where it must go instead — wet ink, a witness, or a notary — plus whether the signer’s state has permanent remote online notarization.

It answers a question you ask it. It does not gate a capture, and it structurally cannot: the capture request has no document-type field for it to read. Wiring it into capture is a code change, not a setting. It persists nothing.

esign.ts:1049-1065

Advisory · persists nothing

Delivery-path policy

POST /v1/esign/delivery-check

Separates an in-app signature, which flows through the engine, from a printed-and-wet-signed return, which bypasses the engine entirely and is verified by a document match plus a present wet signature.

★ It reads who is logged in from the request body. A caller asserts the authenticated recipient rather than the server resolving it — the exact opposite of how the capture route builds attribution. Useful as policy; not a control. It persists nothing.

esign.ts:1119-1155, the recipient field at :1106 and :1124

Advisory · persists nothing

Signing-link and upload policy

POST /v1/esign/email-link-check

Grades a signing invitation against single-use, expiry, intended recipient and intended document, and grades an upload against a document-only type list and a size ceiling. All four link checks fail closed.

The email send is honest-off: no network, no delivery, no persistence. And see the next section — the function that would actually burn a used link has no caller anywhere in production, so a link is not consumed by signing today.

esign.ts:1179-1199

Advisory · persists nothing

Retention policy verdict

POST /v1/esign/retention-status

Applies the retention rule — kept, retrievable, accurately reproducing, and still inside its window — and returns a verdict with the failing condition named.

★ It grades booleans the caller sends it. Whether the record is really retained, really retrievable and really reproduces accurately is measured by a storage layer and handed in. This endpoint never reads bytes, and its own reply says so.

esign.ts:971-993, the asserted booleans at :974-981

Advisory · persists nothing

Certificate-of-completion trail

POST /v1/esign/certificate-status

Checks an audit trail for completeness, ordering and single-document consistency, fail-closed, and projects a summary with no personal data in it.

★ It grades a trail the caller hands it, not one assembled from the ledger. And the certificate document itself is honest-off: this validates a trail, it does not render a certificate.

esign.ts:1009-1022, the supplied events at :1012

Advisory · persists nothing

Consent-ceremony preview

POST /v1/esign/consumer-consent-gate

Runs the four statutory consumer-consent conditions against values you supply, so an operator can see exactly which condition a given ceremony fails.

A preview of the rule, over supplied values, and it persists nothing. The enforcing copy of this gate is wall four on the capture route above, and that one resolves the conditions server-side instead of accepting them. Calling this endpoint does not admit anybody to signing.

esign.ts:1076

Advisory · persists nothing

Clause assist

POST /v1/esign/docassist

Constrained to a supplied set of approved clause templates, with a disclaimer attached to every output and a hard answer that this is not legal advice.

No model is injected. It fails closed to an honest-off verdict and returns no suggestions. It cannot invent legal language today because there is nothing there to invent it.

esign.ts:1208-1224

Built, switched off

Three things are finished and deliberately not running.

A null seam is an honest state and we treat it as one: the code does not guess, does not fabricate, and does not degrade quietly. It reports the absence. Here is every absence that matters, including the one that will disappoint you most.

Held · built, switched off

The cryptographic seal and trusted timestamp

Built: The seal is an injected seam on the engine, and the verification layer over it is complete: it distinguishes an invalid signature, a valid-but-unsealed record, a seal whose bytes have since changed, and a sealed-and-valid record, and it will only call the last one executable.

Held: No seal provider is provisioned. The seam is null, so every capture is recorded captured-and-bound but unsealed, marked with the reason. It never fabricates a seal, a certificate or a timestamp.

So: Nothing captured in this system today is an executed record, and this page never calls one that. Provisioning a provider is an environment change, not a code change.

esign.ts:190 (sealerFromEnv), esign-tamper-seal.ts

Held · built, switched off

The consumer consent substrate — the family path

Built: The gate is written, shared by both signing paths without a fork, and mounted as wall four on the capture route. It resolves the four statutory conditions server-side and denies an unconsented minor even when the ceremony otherwise holds.

Held: The resolver seam is unset. A consumer consent reference therefore resolves to nothing, and the gate returns unbound.

So: ★ No parent or student signature can be captured at all today — the capture is refused with a 422. The family path is the reason this product is defensible and it is currently fail-closed. The only capture that completes today is an institutional one by a staff member, and it lands unsealed. We would rather write that sentence here than have you discover it.

esign-consent-101c-wire.ts, the null-resolver branch

Held · built, switched off

Step-up authentication before signing

Built: The gate ranks the assurance level on the session against the level a document requires, fails closed when the current level is unrecognised, and reports both the required level and what the signer actually has.

Held: Enablement is per tenant and defaults off. Until the flag names a school, the endpoint returns a 503 with the reason attached — a held enablement, not a missing build.

So: It is also not on the capture path: the capture request carries no assurance field, so a signature cannot currently be conditioned on the signer having stepped up. That is a code change too.

esign-stepup-auth.ts; the 503 at esign.ts:1243-1253, gate at :1262

And two things nothing calls at all.

Different from held: these have no switch. They are written and tested and no production code path reaches them. Naming them costs us a feature bullet each and buys the rest of the page its credibility.

No production caller

Burning a signing link after it is used

The natural claim — and the one the module’s own notes describe — is that a signing link is single-use: it is consumed when the signature is captured, so the same link can never sign again.

The function that would burn it has zero callers. Across the application and package sources, excluding tests, the only references are its own definition, its own comments, and a re-export. The same search, in the same run, found its module-mate that is called — the link-status check, wired into a live endpoint — so the zero is a proven absence rather than a pattern that matched nothing.

packages/shared/src/esign-path-email-upload.ts:141; positive control linkStatus at esign.ts:1184

No production caller

A student co-signing as themselves

The guardian wall deliberately includes a student-self arm, so that a fix aimed at the parent half of the family path does not hard-code an over-denial of the student half.

No producer writes the roster edge it reads. The self arm therefore admits zero callers today. It is headroom, not a shipped capability, and calling it student co-signing would be a claim about a path nobody can currently take.

esign-student-coupling-wire.ts, the self-resolver arm

The refusal list

Some instruments legally cannot be signed electronically. Naming them is the point.

A signature product that will sign anything you hand it is telling you something about how carefully it was built. Certain instruments require a witness in the room, or a commissioned notary, and an electronic signature on one of them is not a shortcut — it is a defective instrument that will fail later, expensively, in front of someone who matters.

So the refusal is a published rule and it is fail-closed: a document type marked ineligible can never be routed back into the electronic lane. There is no state, no reason and no default branch that promotes it. Where an ineligible type needs a notary and the signer’s state has permanent remote online notarization, the system attaches an informational notice so the operator knows remote notarization is available — and that notice performs no notarization, books no notary, and honestly says so where a state does not offer it.

Document types and their signing path
Document typeElectronicBecauseGoes to
Master services agreementRefusedRequires a witnessWet ink, with a witnessing party present
Amendment to a notarized agreementRefusedRequires a notaryWet ink and notarization, remote where the state allows it
ContractEligible—Electronic signature
PolicyEligible—Electronic signature
Data processing agreementEligible—Electronic signature
Consent formEligible—Electronic signature
Non-disclosure agreementEligible—Electronic signature

Read the scope of that table honestly, because it is narrower than it looks. This is a GENERIC LEGAL document catalog of seven types, and it does NOT yet enumerate the school document types below — there is no permission-slip entry, no media-release entry, no IEP or 504 consent entry, no athletics-physical entry and no volunteer-agreement entry in it. The refusal rule is real and it is fail-closed: a type the catalog marks ineligible can never be routed back into the electronic lane, by any state, for any reason, through any default branch. But it is refusing generic legal instruments today, not school forms. Saying otherwise would be the exact move this page exists to avoid: a true sentence with the scope stripped off.

The actual paperwork

Six documents, six different signers, six retention obligations.

This is the pile a school actually signs, and the reason a generic tool struggles with it is visible in the second column: the signer changes shape from row to row, and only one of those shapes is the one a general-purpose product models.

School document types, their signers, and why each is distinct
DocumentWho signsWhy it is its own thing
Permission slip for a trip off campusA guardian, for a named childThe one document where “we think we have it somewhere” is the wrong answer at the worst possible moment. It has to name the child, the adult who signed, and the trip.
Media and photo releaseA guardian, for a named child, and revocableConsent that cannot be withdrawn is not consent. A release has to be revocable, and the revocation has to reach the systems that publish — which is why ours is coupled to the consent substrate rather than filed as a PDF.
Handbook acknowledgementA guardian, a student, or a staff memberThe question is never what the handbook says. It is which version was in force on the day in question and who had been given it. That is the sibling product; this is the mechanism it acknowledges with.
IEP and 504 consentA guardian, with the highest sensitivitySpecial-education records carry their own confidentiality regime on top of the general student-records rule. These are the documents where an attribution to the wrong adult is not an inconvenience.
Athletics participation and physicalA guardian, plus a clinician’s sectionPart family consent, part medical record, with a season-bound validity window and a retention obligation that outlives the season.
Volunteer and chaperone agreementAn adult who is not a parent of any enrolled childThe signer here has no roster relationship at all, which is exactly why a system that models only “guardian of” and a system that models only “counterparty” both get this one wrong.

These are the document types the product is for. They are not yet entries in the refusal catalog above, which currently covers generic legal instruments — that gap is named there rather than papered over here.

Compete means beat

The real incumbent is a PDF sent home in a backpack.

Not a software category. Paper. A form photocopied, sent home in a bag, signed on a kitchen counter, and carried back — and it is the incumbent because it costs nothing, everybody already knows how to use it, and it needs no account, no app and no password. Any honest comparison starts by conceding all three, and the table does.

We claim the job outright: this should be how a school collects a family signature. But a table won on every row is a table nobody believes, so the rows we lose are in it, marked as losses.

Comparison across ten axes
AxisA PDF in a backpackThe general signature categoryHere
Cost to the schoolFree. Genuinely, unbeatably free.Advertised per-seat or per-envelope pricing.We lose this row outright to the paper. There is no version of this where paper is not cheaper on the day.
Everyone already knows howYes. A parent needs no account, no app and no password.Advertised as an emailed link requiring no account.We lose this row too. An in-app signature needs a session, and the family path is not even open yet.
Did it come backYou find out by counting paper against a roster, by hand, twice.Advertised status tracking and reminders.The acceptance ledger answers who has and has not, per version, without a second list to reconcile.
Who signed itA signature on a line. Anyone in the house can produce one.Advertised identity verification options, often as a paid tier.Identity comes off the authenticated session on the server. The signer cannot assert who they are, because the field is not in the request.
May this adult sign for this childNothing asks. The form comes back signed and that is the whole check.Not established as a modelled relationship — the category’s signer is a counterparty to an agreement, not a guardian of a minor.A guardian wall on the capture path refuses a child the signer has not been proven to speak for, and writes nothing on refusal. This is the row the product is built for.
Which version was acknowledgedWhatever was photocopied that year. Nobody can reconstruct it later.Advertised document versioning and templates.An acceptance binds the version label and a hash of its content, append-only, and a material change stops the old acceptance carrying forward.
Could the bytes have changed after signingUnanswerable. It is paper.Advertised tamper-evident sealing and audit certificates.The verification layer is built and fails closed — and no seal provider is provisioned, so it honestly reports every record as unsealed and not executable. We are behind on this row today and say so.
What must never be signed electronicallyNot a concept. Everything gets signed the same way.Not established as a published refusal.A fail-closed refusal catalog: an ineligible instrument can never be routed into the electronic lane. Scoped honestly — it covers generic legal types today, not school forms.
A minor at the keyboardNo concept of who is holding the pen.Not established as a modelled signer attribute.A minor wall reads the role off the session through an exhaustive predicate, mounted ahead of the consent gate so it does not depend on any provisioning.
Retention, per document typeA filing cabinet and an institutional memory.Advertised retention and archival policies.The retention rule is implemented and eligibility is computed over stored rows — while the status endpoint grades metrics a caller supplies. Two layers, labelled separately, because blurring them is how a page like this starts lying.

About that middle column. The general-purpose electronic-signature category is DocuSign, Dropbox Sign, Adobe Acrobat Sign and PandaDoc; the K-12 forms-and-workflow category includes Frontline Central. They are named here once, in this footnote, and nowhere else on this page. The column states only what those categories openly advertise, or an explicit "not established" where we could not establish a published claim. Nothing here asserts anything about their internal implementation, their roadmap or their current feature set: we cannot read another company's source, and a guess pointing in the direction that flatters us is a liability rather than a comparison. Neither their code nor their copy is used anywhere in ours. Where we are behind, the rows above say so.

Minors, records and walls

The signers are children and their families, so the defaults are the strict ones.

Minors’ data is consent-gated and never public. Nothing about a student is exposed on this website, and nothing on this page is generated from anyone’s data.

On an evidence row, the reference to a student is opaque: it carries no name, no personal detail and nothing that identifies a child to a reader who does not already hold the roster. Tenant isolation is enforced at the database on every table involved, and every route resolves the school before touching a row, so the records-access wall engages on reads and writes alike.

Reach is split by the shape of the question, deliberately, rather than collapsed into one check. A single evidence row is an ownership question: the signer themself, the guardian of the coupled child, or staff. An aggregate across every signer on a document is a custodian question, so it is staff-only — there is no single owner to test against, and quietly filtering the aggregate per caller would have changed what the endpoint means while appearing to secure it.

Refusals do not leak. A caller who is not staff receives the same refusal for a row that does not exist as for a row that exists and is not theirs, so the identifier space cannot be probed to learn which records or which children are real. Staff keep the true not-found, because a custodian needs to tell those apart.

There is no third-party signature service behind any of this and no egress to one. The engine runs inside our own boundary. When a seal provider is absent the system says so; it does not manufacture a seal, a certificate or a timestamp to fill the space.

Security reports go to [email protected]. Several of the walls described on this page exist because a defect was found and measured rather than theorised, and that is the process working.

Questions

Including the ones with answers we would rather not give.

Can a parent sign a form with this today?

No. The consumer consent gate resolves the statutory conditions on the server, the resolver seam is unset, and the capture is refused with a 422. The family path is fail-closed until a consent substrate is provisioned. The walls in front of it are live and refusing today, which is the part that had to be built first — but a page that let you infer parents can sign would be wrong.

So what can be captured today?

An institutional signature by a staff member. A business party is outside the consumer consent ceremony, so it passes that gate; it still has to clear the staff wall. The resulting record is captured and bound, and it is unsealed, because no seal provider is provisioned. An unsealed record is not an executed one and we do not call it one.

Is a signature here legally executed?

Not today. The four pillars are captured and bound, which is what gives an electronic signature its effect — but the verification layer only calls a record executable once a seal stands over the signed bytes, and no seal provider is wired. Every record therefore reads valid-but-unsealed. Provisioning a provider is an environment change rather than a code change, and until then this page uses the word captured, never executed.

Does the refusal catalog stop a permission slip going out for e-signature?

No, and this is the most important limitation on the page. The catalog is a fail-closed refusal rule over seven generic legal document types, and it runs as a question you ask it — not as a gate on the capture route. The capture request has no document-type field at all, so the route never learns what kind of document it is signing. Wiring the refusal into capture is a code change, not a configuration change. We would rather tell you which gate is a calculator than let you assume it is a control.

Is a signing link single-use?

The link policy check fails closed on a consumed, expired, wrong-recipient or wrong-document link, so a link already marked consumed is refused. But the function that would mark it consumed has no caller in production, which we measured with a positive control in the same search. So nothing burns a link at signing time today. Treat the single-use rule as enforced on read and not yet applied on write.

How is the guardian relationship established?

From one of two things the school already holds: an enrolled contact record binding this adult to this student as a guardian, or a verified, unrevoked, unexpired parental claim. It is the same predicate the evidence read path, the permission-slip family and the depicted-guardian gate on print orders use — we did not invent a second notion of guardian for signatures. If neither holds, the capture is refused and nothing is written.

What happens if someone sends another family’s child in the request?

A 403, and nothing durable is written. The unproven identifier is never quietly replaced with a null, because that would turn a refusal into a silent change in what the ledger records. The refusal is also byte-identical whether the child belongs to another family, to another school, or does not exist at all, so the identifier space cannot be probed for which children are real.

Can a student sign for themselves?

Not today. The guardian wall includes a student-self arm on purpose, so that fixing the parent half did not hard-code an over-denial of the student half — but no producer writes the roster edge that arm reads, so it admits nobody at present. It is headroom rather than a capability, and it would be misleading to list student co-signing as a feature.

Does the audit certificate prove anything about our records?

It proves a trail is complete, ordered and about a single document — for the trail you hand it. It does not assemble a trail from the evidence ledger, and it does not render a certificate document. The same caution applies to the retention endpoint: it grades whether a record is retained, retrievable and accurately reproducing based on booleans the caller supplies, and it never reads bytes. Eligibility, which is computed over stored rows, is the separate one.

Do you use a third-party e-signature service behind this?

No. The engine is ours and runs inside our own network boundary. There is no egress to an external signature service, and nothing fabricates a seal, a certificate or a timestamp when a provider is absent — it reports the absence instead.

What about minors’ data and student records?

Minors’ data is consent-gated and never public. The student reference on an evidence row is opaque, carries no personal information, and is walled by tenant isolation at the database plus the records-access deny set at the route. A cross-signer aggregate is staff-only because auditing a document’s whole posture is a custodian act; a single evidence row is readable by the signer themself, by the guardian of the coupled child, or by staff — and a non-staff caller gets the same refusal for a row that does not exist as for a row that is not theirs.

Is there pricing?

Not on this site. There is no checkout, no card field and no form here — the marketing server holds no state. The honest next step is a conversation by email.

Nearby

Products this one sits beside.

handbook.software

The policy handbook system, and the sibling this product was briefly mistaken for. It owns the document and its versions; the acknowledgement step uses the mechanism described here.

permissionslip.software

The trip-consent front door, where a slip is issued to a roster and chased. The family-walled consent model is shared.

What this page is and is not claiming

The whole posture, in one paragraph.

electronicsignature.software is early access: the walls are wired and refusing, and the family path is not open. Exactly four guards fire when a signature is captured — a staff wall on binding the institution, a minor wall on who is at the keyboard, a guardian wall on whether this adult may sign for this child, and the statutory consumer-consent gate — and all four refuse before anything durable is written. No family signature can be captured today: the consent resolver is unset, so a parent or student capture is refused outright, and the only capture that completes is an institutional one by a staff member. Nothing is an executed record: no seal provider is provisioned, so every captured record reads valid-but-unsealed, which the verification layer explicitly treats as not executable, and the word executed appears nowhere on this page as a claim. The refusal catalog for documents that must not be signed electronically, the delivery-path check and the step-up gate do not gate a capture — the capture request has no document-type, delivery-path or assurance field at all, so wiring any of them is a code change rather than a setting. The retention verdict and the audit-trail certificate grade values the caller supplies; the store-eligibility check is the one that reads a stored row. A signing link is not burned when it is signed, because the function that would burn it has no production caller — measured with a positive control in the same search. Student self-signing admits nobody today, because no producer writes the roster edge it reads. The step-up endpoint returns a service-unavailable code until a per-tenant flag names the school. There is no third-party signature service, no fabricated seal, certificate or timestamp, and no egress. There are no adoption counts, no named customers, no testimonials, no invented figures and no percentage claims anywhere here; the only numbers on this page are four guards, ten comparison axes and the status codes those guards return. Minors’ data is consent-gated and never public, and student references on evidence rows are opaque. There is no pricing, no checkout and no form on this site. The honest next step is a conversation.

Ask about early access Read what is switched off again →

electronicsignature.software is early access. The guardian wall, the minor wall, the staff wall and the consent gate are wired in front of the capture route and refuse today. What is NOT switched on is the consent substrate that would let a parent through, and the seal provider that would let anything be called executed. Both are named on this page rather than left for a renewal call.