Customer guide · Private pilot
From connection to outcome.
Plimie reviews supported infrastructure configuration and usage, then explains credible opportunities for your team to investigate.
The free pilot is invitation-only. Request a sign-in link, open it in the same browser within ten minutes, and confirm sign-in. Create a workspace to begin. The public sample is fictional.
1. Understand access
Confirm the supported connection and assessment scope with your pilot contact before creating a token. Plimie supports a defined set of checks; it does not connect to every infrastructure platform. Use a customer-controlled, account-owned, account-scoped, read-only API token. Never share a master account key or paste a token into chat. Grant read access only to the inventory, firewall rules, traffic analytics, cache configuration, and load-balancer health configuration required by the agreed checks. Confirm that the token has no edit/write permissions. Enter the account ID and token only in the authenticated workspace connection form. Verification checks account ownership and zone inventory; each check's evidence is validated separately during the scan.
Permissions vary by account and plan. A missing scope reduces assessment coverage; it does not prove a feature is disabled. Review the data and access contract.
2. Choose what to assess
Select 1–10 zones and explicitly identify production and test environments, then start an assessment. You can leave and return while it runs. The pilot allows six new scans per workspace per hour. Owners can confirm bot analysis entitlement and optionally provide an origin-transfer unit cost; these are customer-confirmed inputs, not provider billing proof. Recommendations do not assert paid waste.
3. Read an opportunity
- Evidence: what was observed, where, and over which complete days.
- Confidence: the quality of the evidence supporting the finding.
- Next action: a practical investigation or change to review.
- Risk and effort: what to consider before changing production.
- Assumptions: what the evidence cannot establish.
In scan history, choose View coverage to see cache-status observations for seven complete UTC days, where your plan and permissions allow. Zone totals and owner-confirmed host/path cohorts are shown separately, with sampling and daily coverage. These request and visitor-response byte totals are not recommendations or savings estimates. Private/dynamic traffic is not assumed waste, and revalidated response bytes are not origin downloads. Cohort miss persistence does not prove repeated misses for the same object or exclude purge artifacts.
For cache configuration coverage, include read access for legacy page rules, cache rules, and zone settings. The pilot checks active legacy legacy page rules without changing them. Missing access keeps the affected check Explore. Supported cache rules and zone settings receive a conservative configuration review; active legacy page rules and unsupported settings remain review gaps. Only legacy page-rule IDs and priorities are retained, not target URL patterns or action values. Owners must freshly confirm that purges, deployments, development mode, or cache-policy changes did not explain misses in this scan's exact seven-day window. MISS/EXPIRED traffic must occur on at least three distinct days, alongside the other volume and origin-contact gates. This measures cohort persistence, not repeat misses for the same file.
4. Give feedback and track work
Rate a finding Correct, Partially Correct, or Incorrect. Keep that verdict separate from its lifecycle: Reviewing, Accepted, Planned, Implemented, Dismissed, Resolved, or Stale. An accepted finding is not proof of realized savings.
5. Measure the outcome
In an opportunity's Assessment history, choose Use as baseline and Use as follow-up, then Compare selected scans. The comparison reads historical evidence without changing your work status or reported outcomes. Configuration changes do not prove effectiveness. Cache origin-contact share changes are shown only for matching cohorts with complete, unsampled, non-overlapping seven-day windows and matching rule versions; missing or incompatible evidence leaves the change unavailable. Source links open each protected scan.
Technical comparability does not establish equivalent workload, change timing, or causation. Record what changed separately, and report realized monetary value only when you have measured it. Changes in traffic, cache intent, and application behavior can affect comparisons; an observed difference is not verified savings.
To attach a comparison to an outcome, a workspace owner must select both scans, enter the change time in UTC, and explicitly confirm change timing and comparable workload. The server checks evidence and timing again when saving. The outcome preserves the owner's confirmation and source scans; confirmation is not independent verification of causation or savings. Members may still record a standalone customer report, which is labeled separately. Selecting different scans clears the confirmations.
6. Export your workspace
Owners can download a revision-checked NDJSON archive of their workspace, evidence, assessment history, feedback, outcomes, and audit records. Credentials and sign-in data are excluded. Wait for scans and edits to stop; a concurrent change cancels the download. The browser supports files up to 100 MiB. Read the export format, limits, and paginated API guide. Store exports securely; they contain private workspace data.
What each check means
For managed WAF, an execute target must match a provider-listed managed ruleset in the WAF phase, and the entrypoint must agree with its inventory. Missing metadata, uncertain applicability, or conflicting reads remain coverage gaps. Confirmed deployment does not prove that overrides, exceptions, or individual rules provide effective protection.
Current live coverage: managed WAF deployment, daily HTTP traffic, owner-confirmed cache cohorts with supported configuration review, the tiered caching setting, standard load-balancer health-monitor configuration, and owner-confirmed bot analysis checks with daily score analytics and bounded policy inspection. Real customer cache behavior and entitled bot-field access/classification still need validation. Custom load-balancer rules, pool sets, weighted steering, omitted fields, and incomplete inventory remain Explore. Monitoring-only or disabled group members do not count as health steering. Fallback-only pools are excluded, and production/test classification inherits the selected zone context. Sampled or incomplete traffic cannot support a finding under the pilot's current policy.
- CF-001 · Managed WAF deployment
- Checks both zone and applicable account scope before concluding no deployment exists.
- CF-007 · Cache realization
- Looks for repeated origin contact in eligible static traffic. Private, authenticated, API, and intentional bypass traffic is excluded.
- CF-006 · Tiered caching
- Requires an authoritative off state and meaningful cacheable traffic. It is grouped under the cache opportunity when both apply.
- CF-008 · Health monitoring
- Accounts for monitor groups as well as legacy monitors across referenced pools.
- CF-003 · Bot-signal use
- Requires owner confirmation of the required bot-analysis subscription and edge-function signal use, plus enough non-verified scored traffic. Unknown consumption cannot become an absence claim.
Owners can provide these answers in zone setup, or leave them unconfirmed. Cache recommendations also require an owner-selected host/path prefix confirmed to contain only public, static content with no private/authenticated traffic or intentional bypass. Each scan records the answers, confirming owner, and time; later edits do not rewrite historical evidence. Confirmations alone do not establish an opportunity: all configuration, analytics, sampling, persistence and volume gates must pass. Bot-score analytics collect seven daily slices after subscription confirmation; sampled or incomplete data stay Explore. Provider field access and classification behavior still require real entitled-customer validation.
Scan notifications
Each workspace member gets an in-app notice for future completed or partial scans. Owners may opt in under Notification preferences to email their own signed-in address; email starts off. Notices link to the scan's evidence and coverage, not a promise of findings. Email contains no findings or credentials. Opt-out cancels pending mail but cannot recall an in-flight message; delivery retries may occasionally duplicate a notice. Provider acceptance does not prove inbox delivery. Notifications and preferences are included in owner exports and removed with workspace deletion.
Weekly value reports
Workspace reports cover seven complete UTC days, from Monday 00:00 to the following Monday (end exclusive), and appear after that boundary. They preserve period findings, confidence changes against earlier assessments, coverage gaps, work-status changes, and customer-reported outcomes. The first report identifies workspace creation; days before it existed do not imply coverage. Reports are historical, not a current assessment or an automatic proof of savings. Amounts retain their own currencies and measurement windows and are not totaled. Owners may separately opt in to report emails; scan email consent does not enable them. Email is off by default and contains only a protected link. Only signed-in workspace members can follow report/source links. Owners can export report records; workspace deletion removes them. Generation and delivery may be delayed, and retries can duplicate email.
Empty or partial assessments
No findings means no eligible opportunity was detected in the covered scope and window. It is not a guarantee that an environment is fully optimized. Permission errors, unavailable datasets, and insufficient traffic should be resolved or acknowledged before drawing broader conclusions.
Older records
Use the Load more controls for older findings, scans, assessments, reviews, and measured outcomes. Each page is bounded, but the lists have no total record cap. If the workspace changes while you browse, refresh the affected list before continuing. Expanded scan and finding lists remain in place during automatic polling; refresh them to see new changes.
Rescans, schedules, and workspace deletion
Start a new manual scan after changes and inspect its coverage. Owners can also enable daily or weekly rescans on an active connection; the scheduler skips a run when the interval has not elapsed, a scan is already in progress, or selected zones are not ready. A new assessment shows whether a finding persists, changes, is no longer detected, or cannot be assessed. Missing evidence and failed scans never establish resolution. Your work status, dismissals, feedback, and measured outcomes stay separate and are not overwritten. Completed assessment history remains available, and past recommendations are labeled historical. Token rotation requires selecting zones again. Disconnect erases the stored token and cancels active scans; also revoke the token in your infrastructure account. Owners can delete the workspace after confirmation, which cancels in-flight scans, wipes stored credentials, and removes the workspace records.