> ## Documentation Index > Fetch the complete documentation index at: https://docs.puntego.com/llms.txt > Use this file to discover all available pages before exploring further. # Product Map and test logins > Map your product, give Puntego a test login for your staging site so it can learn the pages behind sign-in, and review the visual skills it proposes. Product Map brings three kinds of evidence together: the targets and actions your team declares, the public pages Product Scout has indexed, and what Puntego learns by signing in to your **staging site** with a test login you give it. These have different trust levels, and Puntego keeps them visibly separate: a saved login is never presented as a working sign-in, and a learned control never becomes something the guide can click without your explicit say. ## Give Puntego a test login Open **Dashboard → Knowledge → Product Map** as an owner or admin and choose **Add test login**. You confirm the change with MFA. 1. **Staging site** — an address on one of your [verified domains](/domains), or a subdomain of one, such as `https://staging.example.com`. To use a separate staging domain, verify it first in **Install → Domains**. 2. **How the test account signs in**: * **Sign-in form**: the path of your sign-in page (for example `/login`), an email or username, and a password. * **Sign-in link**: a link that signs the test account in without a password. The whole link is encrypted, path included. * **Another method**: HTTP Basic, a bearer token, or a session cookie. 3. **Pages to learn** and **Pages to skip** — path prefixes. Puntego only opens pages under the first and never the second. 4. Save, then choose **Check sign-in**. Puntego signs in once and opens the first page to learn. The card shows **Sign-in works**, or what went wrong and what to do. Use a **dedicated test account with test data only**, with the narrowest role that can see the pages you want learned. Accounts that use single sign-on or two-step verification are not supported. The password or link, and the email or username of a sign-in form, are encrypted for your workspace and never shown again: you can replace them or delete the test login, and every change and check is recorded in **Test login activity**. ## What Puntego does with it Puntego signs in and reads your product **without changing anything**: * **One write, ever: the sign-in.** While signing in, Puntego sends exactly one request that submits data, to your staging site's own address. After that, it only reads pages (`GET`). It never clicks a button, submits a form, opens a popup, starts a download, or follows a link to another site. A page that signs out or acts (its address names an action such as delete, cancel or checkout) is never requested, whether a link, a redirect or a script on the page points there. * **Links that act are never opened.** Puntego records them but does not open links that sign out, delete, cancel, pay, rotate keys, accept invitations and the like — by the words in their path, a `data-method` other than `GET`, or a name that reads as a payment, a contract, or an irreversible step. Query strings are never followed. * **robots.txt is respected**, as `PuntegoBot` ([RFC 9309](https://www.rfc-editor.org/rfc/rfc9309)). Staging sites often block every crawler; to let Puntego learn, add a group for it: ```text theme={null} User-agent: PuntegoBot Allow: /app ``` * **It stays on your staging address.** Every page and every redirect hop is checked against the exact origin and your pages to learn; private network addresses and address changes mid-run are refused. robots.txt applies to redirects and to requests a page makes, too. * **It keeps structure, not content.** Puntego stores paths, the short visible names of buttons and links, and what pressing them shows (a dialog, a page, a status message). It never stores page text, values you typed, cookies, headers, page bodies, or screenshots, and the test login is never sent to an AI model. * **If your site signs it out**, Puntego keeps what it learned so far, stops, and tells you in the Inbox. It does not sign in again on its own. Each run is capped at 100 pages, 200 controls, 2 MB of evidence, and 120 seconds. A run that finds more pages than it may open is **partial**: **Recent runs** says how many pages it left unopened, and Copilot and the proposals keep using your latest complete run. Narrow the pages to learn (allowed path prefixes) so a run can open everything it finds. ## Visual skills, proposed automatically After a run, Puntego proposes a **visual skill** for each named control it found while signed in that has a stable locator (`data-gp-id` or an `id`): the control, plus a pointer to it with typed "After this, expect…" checks read from your page's own structure — the dialog it opens, the page it leads to, the status it announces. You can declare one on the control with `data-gp-postcondition="visible:.toast"`. Controls that pay, delete, cancel, sign, or sign out are never proposed automatically. A rejected proposal is not raised again. In **Proposals**, a visual skill is one card. **Approve** it, then **Publish to guide**: the guide can then point at, scroll to, or spotlight that control for visitors. It still cannot click it. When you want the guide to press it, turn it into a skill in **Guides → Skills**; new skills start off. See [Skills](/verified-actions#skills). If a later complete run opens the control's page and no longer finds the control, its card says **No longer on the page**. It keeps its evidence, but it can't be approved or published, and Copilot stops drafting guides with it. Reject it to clear it. A run that doesn't open a page (for example, because robots.txt now disallows it) never marks that page's controls as gone. ## Learning again on a schedule Your plan decides how often Puntego can re-learn on its own: | Plan | Scheduled re-learning | | - | - | | Free | Manual runs only | | Starter | Weekly | | Growth | Daily or weekly | | Scale, Enterprise | Every 6, 12, or 24 hours, or weekly | A scheduled run compares what it sees with the last complete run and lists what changed. It can propose visual skills and repairs, but never approves or publishes them. If a run fails or the sign-in stops working, the **Inbox** says what happened and what to do. If your plan changes and no longer includes a schedule, Puntego pauses it and tells you there. ## Monitoring public pages Product Scout scans the public pages of your website sources, records bounded snapshots, and detects meaningful changes. You can pair a test login with a public source to see how many of its indexed pages fall inside the pages to learn; this count is labeled **indexed public snapshot** and never means a signed-in visit. ## Security contract * Only workspace owners and admins can see or manage test logins; only owners approve, publish, or roll back. * Adding, editing, checking, and deleting a test login, and every run, schedule, and proposal change, require a recent MFA confirmation. * The staging address must be a verified domain of your workspace or a subdomain of one, checked when you save and again before every run. * A sign-in check is limited to 5 attempts per test login every 10 minutes, and a rejected sign-in is never retried automatically, so a test account isn't locked out. * Deleting a test login destroys the saved password or link and stops its schedule; what it learned and its activity remain. * A workspace can keep up to 25 test logins. Each list of pages to learn or skip accepts up to 20 paths. * Learning records are included in workspace export without credentials. Completed history defaults to 90-day retention while the latest successful result per test login is kept. Ingest and inspect the documentation knowledge used in Guide answers. Declare governed actions and require confirmation and outcome receipts. Review data handling and visitor privacy controls. Review the broader deployment and security model. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.