Perimeter distinguishes **seeds** — the starting points you tell it about — from **assets**, the inventory it builds by expanding those seeds.

The difference matters more than it looks. A seed is a **permission slip**: it is what authorises Perimeter to go looking. An asset is a **record of something that exists**, and carries no authorisation of its own. That is why scans start from your seeds rather than from your inventory, and why deleting a seed does not delete the assets it found.

## Seeds

A seed is a root you own. Add them under **Seeds**.

Supported seed types: **domain**, **subdomain**, **ip**, **ip_range** and **asn**.

To add one, pick the organization, choose the type, enter the value and confirm ownership. The ownership checkbox is not decorative — see [Security and acceptable use](security-and-acceptable-use).

### Domain verification

Domain and subdomain seeds can be required to prove control before they authorise anything, via a DNS TXT record or a token file served over HTTPS at a well-known path. Perimeter stores only a hash of the token.

> **This requirement is a setting your organisation turns on, and it is off by default.** With it off, a domain seed you add starts working immediately without a challenge. With it on, domain and subdomain seeds are skipped by scans until you verify them.
>
> It was made optional because the checks that carry real exposure — port checking and template scanning — moved behind a separate signed **scan authorization** instead. What verification still gated was an HTTPS request, a TLS handshake, a CORS preflight and a favicon fetch: what any browser does when it loads a page. **If you want proof of control enforced before Perimeter touches anything, turn the requirement on** in the organisation's settings.

IP, range and ASN seeds never carry an ownership challenge — DNS-based proof doesn't apply to them.

Where the requirement is on, challenges expire. If one lapses, the seed stops being scanned until you re-verify. When verification succeeds, an initial discovery scan is queued automatically.

Perimeter records what actually happened rather than flattering it. A seed added while the requirement was off is stored as unverified, not quietly marked verified — so if you turn the requirement on later, you see the truth. Assets found through such a seed are labelled "auto (unproven)": they will be scanned, but the interface does not claim you proved ownership when you didn't.

### Working with seeds

Each seed row offers **Discover**, **Move to…** (reassign it to another organization) and **Delete**. Select several and use **Run Discovery** to process them together.

You can run discovery on **selected seeds** rather than the whole organization — useful when you have added one new domain and don't want to re-expand everything. The confirmation dialog tells you what is in scope before you commit.

## Assets

The **Assets** screen is your inventory. Asset types are domain, subdomain, ip, ip_range, service and web_app.

Columns include type, display name, normalized key, organization, subsidiary, service owner, technical owner, status, source, and counts of findings and contacts.

### Adding assets directly

**Add Asset** takes an organization, type, identifier and display name, with a required ownership confirmation.

### Importing

Import accepts `.xlsx`, `.xls` and `.csv`. Ownership confirmation is required. After the run you get a summary of how many rows were imported, how many were skipped as duplicates, and any row-level errors.

Seeds have their own import template, separate from the asset one.

### Filtering and bulk actions

Filter by search text, asset type, status (Active / Inactive / Archived), source (Manual / Import / Discovery), subsidiary, whether the asset has findings, contact, and creation date range.

Select rows — or **Select all N matching** to go beyond the current page — then reassign organization, change status, **Export CSV**, or delete. Exports have a row cap; the UI tells you when you've hit it.

### Asset detail

Click a row to edit its display name, organization, status, service owner and technical owner, view parent and child relationships, and archive it.

## How assets get discovered

Beyond what you add manually, assets arrive from scans. A candidate found during a scan does not go straight into your inventory — it passes through a confidence gate first. High-confidence candidates are promoted automatically; anything less waits for you in the review queue.

A single scan promotes a bounded number of new assets, so a large estate settles over several scans rather than all at once. If your contract records a maximum asset count, a discovery that would exceed it is reported as a coverage gap on the scan rather than silently dropped — you see what was found and why it wasn't recorded.

See [Reviewing discovered assets](reviewing-discovered-assets).