Skip to main content
Launchpad mark
Launchpad by Tessera
Onboarding Wizard (Interview site), development instance
Register
Registration runs the real Onboarding Engine over the Application Product and the delimited driver file: the PDF splits into statements, the driver ingests, the matching runs on the account key, and the Decision-Analyzer produces the structure, the field mapping, and the auto match results. The LLM-driven confidence is a keyless stand-in until the API key is set.

Technical-owner intake

Onboarding starts with the technical owner of the legacy application signing in and registering the product. Give a small set of facts about it, then provide the product's history. The metadata is handled confirm-by-exception: you type the identity and the intent, ingestion detects what it can from the files, and you confirm or correct. The output format and the real document count are read straight off the history.

Development instance. SSO is a stand-in field, not a real identity provider. History is ingested over synthetic fixtures.
Sign in (single sign-on stand-in)
In production this is the enterprise single sign-on identity. Access is deny-by-default: the enterprise authorizes who answers each kind of question, and ACaaS routes by question kind.
Register the product
This is partly an instruction to the system: it tells ingestion how far back to learn.
A rough volume estimate, kept as a completeness check. Average per month times months is the expected count, shown against the documents ingestion actually evaluated.
The true format is read off the history files. If your entry differs from what ingestion detects, the detected value wins and the difference is shown.
Provide the history: Application Product plus matching driver file

Provide the product history as the Application Product (the current legacy output the enterprise CCM system produces, that is, the finished documents) and the matching delimited driver file (the structured input that produced them). The engine pairs each finished document with the input record that produced it, on the pairing key below. Choose how the history is acquired.

Reading real enterprise paths is represented in this development instance. The path is accepted and a found-file confirmation is shown, but no enterprise filesystem is read here; the engine learns over the synthetic fixtures. In production ACaaS reads the referenced artifacts in place.
Application Product (finished documents)split at the Application Product step (PDF splitter plus normalizer)
Driver file (input data)ingested at the Driver Ingestion step (delimited reader plus pairing)
Sample basissynthetic-100 (PNB-SYN corpus + keyed driver file)
The key that ties an input record to its output document, for example the account number. Format and record count are read off the file; the pairing key is the owner's input. The driver file you register here is also the live runtime feed, not a one-time learning file.
Cancel