Getting started

Updated

Assay installs like any other product in the Scalpels catalog. Because it is Experimental, starting a new install needs the Supporter tier or a partner listing on your team. Connect GitHub and Laravel Cloud first, then open Catalog, choose Assay, review its requirements and select Deploy. Install a product covers the general flow, including how to resume a failed install.

What the install creates

Scalpels forks artisan-build/assay into your GitHub account and creates a Laravel Cloud application and environment running PHP 8.5. It then provisions exactly what Assay's manifest asks for:

Resource	What Assay uses it for
Serverless Postgres 18 database	Every Assay table: runs, usage, captured content, flags, datasets, members and credentials. Assay's queries are written for PostgreSQL.
Managed queue	Accepted telemetry is not written during the HTTP request. Each accepted batch becomes an encrypted queued job that a worker processes.
Object storage bucket	The erasure journal. Every subject erasure is also written as a file outside the database so it can be replayed after a database restore.
Scheduler	Reconciles incomplete runs and held content every minute, prunes encrypted queue residue every minute, and runs retention pruning daily at 02:00.

There is no cache resource. Assay does not use a cache store of its own; framework tables and scheduler locks live in the database.

Scalpels writes one application value: ASSAY_ERASURE_KEY, a dedicated key Assay uses to build erasure tombstones. Scalpels generates it and writes it into your Cloud environment once, the first time the environment is provisioned without it. It is never your APP_KEY and it is never replaced, because every tombstone in the erasure journal depends on it. You are not asked to type any value during the install.

After the first deploy, Scalpels runs php artisan migrate --force, which creates both the Assay tables and the Built for Cloud tables for members and credentials.

Sign in

Assay has no public sign-up. The deployment's root address shows a landing page with an Open application button and a link back to Assay's page on Scalpels.

If the deployment page in Scalpels shows an Open Assay button, use it to sign in through Scalpels. Whether an installation uses Scalpels for sign-in is chosen by that installation's Owner, inside the app; see Per-installation sign-in.

Otherwise, create the first Owner yourself. From a local checkout of your fork, with the Laravel Cloud CLI signed in and pointed at your application, run:

php artisan create-admin --environment=<environment-id>

The command asks for an email, name and password and creates the Owner in that Cloud environment. Sign in at /bfc/login with those details.

Find your way around

After signing in you land on a small dashboard with a Go to Settings button. Settings, at /settings, is where you manage members, sessions and installation credentials. Personal credentials are deliberately switched off in Assay.

Assay's own screens are not linked from that dashboard. Open them directly:

Address	Who can open it	What it is
`/assay/dashboard`	Every Owner, Admin and Member	The usage dashboard
`/assay/risk`	Every Owner, Admin and Member	The full-capture risk and operations guide, including payload-filter recipes
`/assay/datasets`	People with content access	Curation and datasets
`/assay/access`	Owners, and Admins with content access	Content access overrides

First steps

Invite the people who need to see telemetry from Settings. Every admitted Owner, Admin and Member can read usage. Owners and Admins can also read captured content by default; Members cannot.
Issue an installation credential for your first reporting application and install the client package in it. See Connecting your apps.
Trigger an AI call in that application, make sure its queue worker is running, and open /assay/dashboard. The Pipeline Health table lists the application once its first batch has been processed.
Read /assay/risk before you switch any application to full content capture.