By the end of this chapter you can

• Say what a governed digital record is and which paper documents Paper to Glass replaces.
• Place a form in one of the nine categories and say which neighbouring module owns what this one leaves out.
• Name the five standards the module is built against and the nine ALCOA+ attributes, and say where in the module each is met.

What Paper to Glass does

Paper to Glass converts any paper form, checklist, round or inspection into a governed digital record. The record can be filled in on the floor with no signal, scored, signed, trended, and turned into follow-up work: a work request, a nonconformance report or an observation. It replaces the mobile forms and inspection tools a business usually pays for, such as SafetyCulture (iAuditor) ^[7] and GoFormz ^[6]. The module specification also names Fulcrum, GoCanvas, ProntoForms, Jotform, Operations1 and Microsoft Forms with Power Apps as tools it replaces.

It is also the first spoke on the platform's hub, and the engine that later modules reuse for their own data capture. A form built here is not a special case: the same designer, versions, offline queue and typed answers carry the work of the modules that come after.

The nine categories

Every template carries one category. Choosing it is the first act of the first lab, and it decides who acts on the form.

What is in, and what is not

The module is wide enough to replace the tools above and narrow enough to leave documents, step-enforced production and statistical charts to the modules built for them.

• In: form designer with versioning and a template library; AI-assisted ingestion of scanned and PDF paper forms with human review; scheduled and ad-hoc execution; offline-first mobile capture with photo, signature, GPS and barcode evidence; scoring, failed-item actions, routing and approvals; field-to-table mapping so a submission can create records in other modules.
• Out: controlled SOP authoring and approval (M06 Document Control); step-enforced production execution with material verification (M04 MES); SPC charting of numeric results (M09 consumes form results).

Eleven capabilities in three tiers

The capability map lists what the module does, and each capability carries a tier. MVP must exist for a small or mid-size plant to cancel the incumbent subscription with confidence. STD is parity with mainstream tools, what a buyer expects in a demo. BIC marks best-in-class differences, such as those made possible by AI and by the shared spine. MVP and STD are required for the course; BIC is advanced work.

The standards, and what each one is used for

ALCOA stands for Attributable, Legible, Contemporaneous, Original and Accurate. The plus adds Complete, Consistent, Enduring and Available. They are easy to recite and hard to meet with paper, because a sheet cannot show who changed a number or when. Each one becomes a design decision in a digital record.

References

1. ISO 9001:2015 Quality management systems: requirements (clause 7.5, documented information). https://www.iso.org/standard/62085.html
2. eCFR: Title 21, Part 11, Electronic records; electronic signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
3. FDA: Data integrity and compliance with drug CGMP: questions and answers (2018). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers
4. MHRA: Guidance on GxP data integrity (2018). https://www.gov.uk/government/publications/guidance-on-gxp-data-integrity
5. W3C: Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
6. GoFormz: mobile inspection management. https://goformz.com/use-cases/inspections
7. Microsoft Store: SafetyCulture (iAuditor) feature list. https://apps.microsoft.com/detail/9nblggh5flq2

By the end of this chapter you can

• Name the eight frm_ tables and say what each one holds.
• Explain why a published version is immutable and how a submission stays pinned to it.
• Say why answers are typed rows and not one JSON blob, and why the server's clock is the record time.

Eight tables on the shared spine

Every table in the module starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. The module has no people table, site list or file store of its own: it points at core_person, core_site, core_job_role, core_uom, core_data_tag, core_attachment and core_e_signature. Its own tables share the prefix frm_.

The table below is the full definition: every column the module adds to the standard ones, with its type and whether it is required (marked req). Types are written as in the specification: text, int, num (a decimal number), bool, ts (a timestamp with time zone), uuid and json (jsonb in Postgres); an arrow means a foreign key to that table. It is what your agent builds from in Session 2.

subject_type and subject_id on a submission name the thing the form was filled in about (a machine, a room, a vehicle), which is what lets the failure Pareto group by asset. geo holds the GPS stamp when one is taken, and sort_order keeps a version's fields in the order they are asked.

Look at the allowed values before you design anything. A template's category is one of the nine in chapter 1 and its status is draft, published or retired. A field's type is one of text, number, choice, multi_choice, date, datetime, photo, signature, barcode, gps, file, table, calculated or section. A target is an equipment, location, area, person, role or site. A submission moves through in_progress, submitted, in_review, approved, rejected or void.

Versions: a published form never changes

Two things carry a status here, and they are easy to mix up. The template header, frm_template, has the status draft, published or retired: whether the form as a whole is still being built, in use, or no longer used. Each version is a row in frm_template_version, with the schema, logic and scoring stored as JSON ^[3], and its state is read from published_at.

A draft version is a row whose published_at is empty. Anyone with the right role can edit it, and its frm_field rows point at it while the form is being built. Publishing sets published_at and published_by, and from then on that row and its fields are read-only. A change to a published form is a new version row (version_no plus one, a draft again) with a change note, and frm_template.current_version_id moves to it when it is published. Old published versions stay exactly as they were, never edited or deleted.

Every submission records the version it was filled in on. A month later, when someone asks what question 7 said on the day of a failed inspection, the answer is in the pinned version, not in whatever the form looks like now. ISO 9001 asks for exactly this control of documented information: a template version is documented information, and a record shows which version was in use ^[1].

Answers: one typed row each

When a form is submitted, each answer becomes a row in frm_response with the field key and a value in the column that matches its type: value_num for a pressure, value_bool for a yes or no, value_ts for a date and time, value_text for words, and value_json for the rest (a table, a multi-choice). Two flags are set as the answer arrives: out_of_limit, when a number falls outside the field's limits (lsl and usl on frm_field), and failed, when a scored or pass-fail item fails.

Time: the server is the record clock

A phone's clock can be wrong, set by hand, or changed after the fact. The record time therefore comes from the server's clock when the submission is received, and the device's capture times are kept separately beside it, together with device_id and the captured_offline flag. Both are needed: the server time says when the record became part of the system, and the device time says when the person actually answered. That is the contemporaneous attribute of ALCOA+ ^[4]. Timestamps should be written in a standard, unambiguous form such as RFC 3339 ^[5].

Exercise · Model one real form15 minutes

You need: One filled-in paper form from your business, the standard columns list from this chapter, and your AI coding agent

Use the form you chose in Session 1. Work on paper or in a text file first; the agent comes in at step 5.

1. 1. Choose the category from the nine in chapter 1, and write why in one line.
2. 2. List every item on the sheet as a field: give it a field_key, a label and one of the allowed field types. Mark which are required.
3. 3. For every number, write its unit, its lower limit (lsl) and its upper limit (usl) as the sheet or the standard states them. If the sheet gives none, write "none" and ask the person who fills it in.
4. 4. Mark every item that must carry a photo, a signature, a barcode scan or a GPS stamp, and the one answer that should create follow-up work when it fails.
5. 5. Ask your agent: "Show me, for this form, the rows that frm_template, frm_template_version, frm_field and one sample frm_submission with its frm_response rows would hold. Use typed value columns, not one JSON blob." Read the answer against your list.
6. 6. Check three things in what it wrote: every number is in value_num with out_of_limit set by the limits; the submission names its template_version_id; and no timestamp comes only from the phone.

Outcome: A one-page field list for a real form, with types, limits and evidence marked, and a sample set of typed rows your agent generated and you checked.

References

1. ISO 9001:2015 Quality management systems: requirements (clause 7.5, documented information). https://www.iso.org/standard/62085.html
2. eCFR: Title 21, Part 11, Electronic records; electronic signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
3. IETF RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format. https://www.rfc-editor.org/rfc/rfc8259
4. MHRA: Guidance on GxP data integrity (2018). https://www.gov.uk/government/publications/guidance-on-gxp-data-integrity
5. IETF RFC 3339: Date and Time on the Internet: Timestamps. https://www.rfc-editor.org/rfc/rfc3339

By the end of this chapter you can

• Describe how an assignment, a recurrence rule, a due window and a grace period decide what is due and overdue.
• Explain how an offline submission is queued, synced without loss and kept from duplicating.
• Trace a failed answer to a linked record in another module and a submission through review to approval.

Assigning a form to a target

An assignment links a template to a target: an equipment, location, area, person, role or site. It has an assignee (a person or a job role), a recurrence rule, a due window and a grace period, and the next time it is due. A QR code on the asset opens the right form for that asset in one scan, which is how a round of the same eight gauges stays a round and not a search through a folder.

The recurrence rule is a line of text in the iCalendar standard, RFC 5545 ^[1]. Two examples: FREQ=DAILY is every day, and FREQ=WEEKLY;BYDAY=MO,WE,FR is every Monday, Wednesday and Friday. The rule is read with a start date and time to give the series of due times; the module stores the next one in next_due_at.

Offline-first capture

A plant has dead spots, and a form that needs a signal fails exactly where it matters. Offline-first means the phone holds everything it needs to run the form (the published version, the lists, the limits), saves each answer as it is entered, and puts a finished submission in a local queue. When a connection returns, the queue is sent.

• Auto-save so a locked screen or a dead battery loses nothing already entered.
• A local queue that survives the app being closed, and shows the person how many submissions are waiting.
• Conflict-free sync: each submission is created on the phone with its own id, so 50 queued submissions are 50 separate records and none can overwrite another. Sending the same submission twice must not create two.
• Device ID and capture times preserved, with captured_offline set, and the server's clock as the record time (chapter 2).

Evidence and signatures

Each question can carry evidence: a photo with markup, a GPS stamp, a scanned barcode, a file. The signature is an e-signature stored through core_e_signature and linked from the submission, and it carries a meaning: the reason the person is signing, such as "performed" or "approved". A regulated record needs the meaning, the person and the time to be part of the signed record ^[3][4].

A failed answer starts work

A failed or out-of-limit answer is not the end of a record. It can create a record in another module and link back to it. Each such record is a row in frm_triggered_action with an action type, the target module and the new record's id, and a status of pending, created or failed.

The six action types and the modules M05, M08 and M11 come from the module specification. The one-line meanings are this course's plain wording, and the specification names no owner for notification or webhook, so none is claimed here.

The status matters: pending is waiting to be made, created means the target record exists and its id is stored, failed means it could not be made and a person must be told. Never let a failed action pass silently; an unrouted failed answer is the same as a form nobody read.

Review and approval

After submission, a supervisor sees the form in a review queue. They can approve it or reject it with a comment, and a form can have more than one approval step. The submission's status says where it is: submitted, in_review, approved, rejected, or void. Review is a design choice: a daily pre-start check might need none, a permit must have it.

Events the module sends and receives

The module publishes frm.submission.submitted, frm.submission.approved, frm.response.failed and frm.assignment.overdue. It consumes mes.operation_run.started (so launching a production run can open the line checks) and cmms.work_order.completed (so finishing a repair can open a post-maintenance inspection). Field-to-table mapping, webhooks and the event outbox make these links without code in the form itself. In this course's sessions only frm.assignment.overdue is built as required work (Session 4); the other three events, the field-to-table mapping and the webhooks belong to integration mapping, a BIC capability, and are an optional extension step in Session 4.

Exercise · Prove it offline, then fail an item20 minutes

You need: A phone with your built form open, a second device or the database, and a way to put the phone in airplane mode

Use the form you modelled in chapter 2 and the build from Session 3 or 4. Use synthetic data only; do not use a real person's name or real equipment tags.

1. 1. Open the form on the phone while connected, and confirm it loads its published version. Note the version number.
2. 2. Switch the phone to airplane mode. Complete and submit the form three times, with one answer deliberately outside its limits.
3. 3. Look at the phone's queue: three submissions waiting. Close the app completely and reopen it; the queue must still show three.
4. 4. Turn the connection back on and let the queue sync. In the database, count the new rows in frm_submission and check captured_offline and device_id on each.
5. 5. Check the times: the device's capture times must differ from the server's record time, and neither may have overwritten the other.
6. 6. Find the out-of-limit answer in frm_response and check out_of_limit is set, then find its frm_triggered_action row and the linked record it created.
7. 7. Approve one of the three in the supervisor queue, reject one with a comment, and check the status of each.

Outcome: Three offline submissions arrive once each with both clocks kept; the failed answer has a linked record; one submission is approved and one rejected with a comment.

References

1. IETF RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar). https://www.rfc-editor.org/rfc/rfc5545
2. W3C: Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
3. eCFR: Title 21, Part 11, Electronic records; electronic signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
4. European Commission: EudraLex Volume 4, EU GMP guidelines (includes Annex 11, computerised systems). https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en
5. GoFormz: mobile inspection management. https://goformz.com/use-cases/inspections

By the end of this chapter you can

• Describe paper ingestion as a job with a human review step, and say what is stored as provenance.
• Define the five KPIs and check a dashboard against a hand count.
• Plan a migration from an incumbent tool and state the four tests that mean the module is done.

Paper ingestion with a person in the loop

Typing a hundred paper forms into a designer is slow work. Paper ingestion lets a person upload a PDF or a photo of a paper form; AI proposes the fields, their types, limits and layout; and a reviewer accepts or edits each field one by one. Nothing the AI proposes becomes a live form until a person has reviewed it.

The job stores the file it came from (source_attachment_id), the proposal (extracted, as JSON), an average confidence (mean_confidence), who reviewed it and when, and the version it produced. The version also records source_ingestion_id. This is the provenance: anyone can later see which fields came from the machine, which a person changed, and who approved them, which is the attributable attribute again ^[5]. The proposal itself is also recorded as an AI suggestion in core_ai_suggestion.

Measuring whether it works

Five KPIs come with the module. Each has a definition that can be counted from the tables in chapter 2, so a dashboard can be checked against a hand count.

The lab seeds synthetic submissions on purpose. If the dashboard says 75% and your hand count of the seed says 75%, the dashboard is right for that data; if it differs, the definition in the query is wrong or the rule for "on time" from chapter 3 was not applied the same way. A KPI nobody can reproduce by hand is a number nobody should trust.

Moving off the old tool

Per the module specification, SafetyCulture, GoFormz and Fulcrum all offer CSV or API export of templates and submissions. That is the specification's statement, not something the product pages cited here confirm, so check what your own tool gives you on the vendor's own page before you plan. The migration rule is the same as for versions in chapter 2: templates import as draft versions, for a person to review and publish, and historical submissions import as read-only archived records. They are evidence of what happened, so they must never be editable and never counted as new work.

1. Export templates and submissions from the incumbent and keep the files untouched as the original.
2. Map each template to a draft frm_template with a version; review and publish the ones still in use.
3. Load historical submissions as archived, read-only rows, with the original dates kept and a note of which tool they came from.
4. Run both systems side by side for a short, fixed period on a few forms, then move form by form.
5. Cancel a subscription only after the export is safe and the replacement has passed its tests. Read the incumbent's contract for the notice period before relying on a date.

Done means testable

The definition of done is four tests an agent can run, and you should run them yourself.

• A form designed in the builder can be executed offline on a phone and syncs with zero data loss across 50 queued submissions.
• A published version cannot be modified, enforced by the database.
• A failed answer creates a linked record in another installed module.
• The completion and overdue dashboards match a hand count on seeded data.

Exercise · Ingest a scanned form and review it field by field20 minutes

You need: A scan or photo of one blank paper form, your ingestion screen, and the person who fills the form in

Use a blank form with no names, signatures or personal details on it. Check with your supervisor that you may upload it.

1. 1. Upload the scan. Check the job appears as an frm_ingestion_job and moves through queued and extracting to in_review.
2. 2. Count the fields the AI proposed, and write the number down.
3. 3. Go through the proposal one field at a time with the person who fills the form in. Accept, edit or remove each one; write down how many you accepted without any edit.
4. 4. Look for every number: check its unit, lower limit and upper limit against the paper. Fill in any that were blank or wrong.
5. 5. Approve the job. Check a draft frm_template_version exists, linked as resulting_version_id, and that source_ingestion_id points back.
6. 6. Work out the paper ingestion acceptance KPI for this one job (accepted without edit ÷ proposed) and record it with the date.
7. 7. Publish the version, then try to edit it in the database or screen. The change must be refused.

Outcome: A draft version created from a paper form after a person reviewed every field, with an acceptance figure from your own count and a published version you could not edit.

References

1. GoFormz: mobile inspection management. https://goformz.com/use-cases/inspections
2. Microsoft Store: SafetyCulture (iAuditor) feature list. https://apps.microsoft.com/detail/9nblggh5flq2
3. Clappia: GoFormz alternatives. https://www.clappia.com/blog/top-goformz-alternatives
4. Guideflow: best digital checklist software. https://www.guideflow.com/blog/digital-checklist-software
5. FDA: Data integrity and compliance with drug CGMP: questions and answers (2018). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers

Choose one answer for each question, then submit. You will see the right answer and why for every question.

1. What is a governed digital record, as Paper to Glass builds it?

AA scanned image of the paper form, filed in a shared folder by dateBA spreadsheet row on a shared drive that anyone on the team can editCAnswers that carry who, when, which version, evidence and follow-upDA PDF of the completed form, emailed to the supervisor at shift end

2. Which module owns controlled SOP authoring and approval, which Paper to Glass leaves out?

AM06 Document ControlBM04 MESCM09 SPC and InspectionDM05 Maintenance

3. A capability is marked MVP. What does that mean?

AIt is optional advanced work that sets the module apart from mainstream toolsBIt matches what mainstream tools offer and what a buyer expects in a demoCIt is required only where the plant's forms are regulated GxP recordsDIt must exist before a plant can cancel the incumbent tool with confidence

4. Which ALCOA+ attribute says a record must be made at the time the work is done?

AAttributableBContemporaneousCEnduringDConsistent

5. What happens to a published template version when the form needs to change?

AIt is edited in place, and the change is described in the version's change noteBA new version is made; the old one stays, with its submissions pinned to itCIt is deleted and recreated with the new questions under the same numberDThe change is made and applied to past submissions so they all match

6. Why are answers stored as typed rows in frm_response and not only as a JSON blob?

AA JSON column cannot be stored in a Postgres database or read by a dashboardBTyped rows always take less disk space than the same answers held in JSONCAuditors under 21 CFR Part 11 do not accept answers that are stored as JSONDLimits, trends and failure counts become simple queries on typed columns

7. A form is filled in offline at 06:00 and synced at 09:30. What does the module keep?

ABoth: the server's time as the record time, and the device's capture timeBOnly the device time, because that is when the person did the workCOnly the sync time, because the server's clock is the only one to trustDNeither; the supervisor types in a time when reviewing the submission later

8. Which RFC defines the recurrence rules (RRULE) used for scheduled rounds and inspections?

ARFC 3339BRFC 8259CRFC 5545DRFC 9110

9. A queued submission is sent twice because the confirmation was lost. What must the server do?

AStore both copies, so that nothing the person entered can be lostBKeep the newer copy and delete the older one that arrived firstCReject both and ask the person to fill the form in againDRecognise it as the same submission and store it once

10. A number answer falls outside the limits on its frm_field row. What should the module do?

ARefuse the whole submission until the person enters a number inside the limitsBRecord it, set out_of_limit and, by rule, start linked follow-up workCCorrect the number to the nearest limit so the record stays within rangeDHold the answer back until a supervisor has reviewed it, then record it

11. In paper ingestion, who decides which AI-proposed fields go into the form?

AThe AI on its own, whenever its mean confidence for the job is high enoughBThe person who uploaded the file, with one approve button for the whole jobCA reviewer, who accepts or edits each field before a version is createdDThe vendor of the incumbent tool, from the template it exported

12. How are historical submissions from an incumbent tool imported?

AAs read-only archived records, and templates as draft versionsBAs new submissions, waiting in the review queue to be approvedCAs editable drafts that the original authors can correct laterDNot at all; they are discarded once the templates have been copied

Submit answers