Not every capture job involves a bot clicking through a legacy UI. Some touch no application at all. They're called Fix Jobs, and they quietly correct data after the fact — like cleaning up a mangled code — without anyone reopening the source system.

Screenshots are important not only as images but as evidence and context. A field value tells you a number. A screenshot tells you what the person actually saw, on which screen, surrounded by which labels, under which system state. Years later, when nobody remembers the application, the second one is often what settles the question.

You can take custody immediately (Post-Capture Export) or defer it (Late Export). Two timings, customer's choice, and it's a governance decision rather than a technical constraint.

Here's a powerful consequence of the layered model: new Layouts can be created later — even after the legacy system is decommissioned. A compliance team asks for a different presentation in 2031 for a system that went dark in 2026? Fine. Layouts depend only on the captured Snapshot data, not on the source system. The source can be long gone and the answer is still yes.

STG's data and presentation model follows a five-layer concept stack: Transition, Schema, Snapshot, Layout, Document. The fun part is that it isn't a set of nesting dolls. A Schema is a blueprint, not a box. Layouts get applied to Snapshots rather than containing them. Documents are produced, not stored. Only the Transition really behaves like a scope.

Snapshots include Preambles — explanatory text blocks at the top of each section. Why bother? Because preserved records often outlive the original application and user familiarity. The person reading this record in 2035 may never have seen the system it came from.

AI agents do the heavy lifting, but every Transition has a single human owner: the Snapshot Analyst. They meet the customer, configure the tooling, supervise the agents, author the RPA scripts, and handle exceptions. The role is the single accountable owner for every Transition.

STG runs on a service-as-software model, and the line that captures it is simple: you do not run the tooling. You never touch Snapshot Capture. You receive durable, searchable, AI-accessible records and interact only with Insights and Transition Governance.

Root Snapshots are field-only snapshots kept current by a nightly job that re-reads the source and updates fields in place. A run can fan out to tens of thousands of jobs — but since each only refreshes field data with no UI crawl, each completes in a few seconds, keeping the whole batch light. The user never waits.

A Live Snapshot and a Final Snapshot of the same record can be identical in content — same fields, same screenshots, same everything. What separates them isn't substance, it's authority: the Live one is provisional and can be superseded; the Final one is locked.

When the customer declares the legacy system read-only, ending operational write, it's not just paperwork. That single declaration triggers Final Capture — the comprehensive run that locks the permanent, canonical record set. After that, the SQL for that Transition is immutable.

No matter the customer or system, a Transition moves through five canonical phases: Designate, Preserve, Decommission, Snapshot Access, and Disposition.

Instead, it assembles each record on demand from its underlying fields, text, screenshots, and attachments producing the same document every time. This gives customers control over where, when, and whether PDFs are exported, making document custody a compliance decision rather than a technical limitation.