You are trying to do a specific thing. Here is how.

The repository is in scope, its credential is read-only, and detectors can see its source and build manifests.

1. 1Confirm the repository falls inside the estate boundary you agreed at kickoff. If it does not yet, see "Set the estate boundary for your first assessment" first.
2. 2Have your platform team provision a read-only credential scoped to the repository or the organisation — never a personal account.
3. 3Add the credential inside the workspace at [PLACEHOLDER: exact console path/label, e.g. Settings > Integrations > Source repositories].
4. 4Confirm the connection shows as read-only and reachable before the next scan is scheduled.

Discovery can read configuration exports and reach the agreed endpoints, without any credential that could change anything.

1. 1List the configuration sources and endpoint ranges you agreed in scoping.
2. 2Provision read-only exports or reachability from the agreed source range only — never an administrative credential.
3. 3Record any access request that will not be approved; it becomes a documented blind spot in the final report rather than a silent gap.
4. 4Confirm with your engagement contact once each source is reachable.

A written boundary exists — business units, environments, regions and systems in and out of scope — before discovery runs.

1. 1Write the boundary down before kickoff: business units, environments, regions, repositories, endpoints and appliances in scope, and everything explicitly out of scope.
2. 2Name an owner who can settle a scope dispute inside a single conversation.
3. 3Enter the boundary in the workspace at [PLACEHOLDER: exact console path/label, e.g. Settings > Workspace > Scope].
4. 4Leave open questions open rather than guessing — record each one with an owner and a date to close it by kickoff.

Your team signs in through your existing identity provider, and access follows your own joiner-mover-leaver process.

1. 1Identify your identity provider and confirm it supports the protocol AutoPQC expects. [PLACEHOLDER: supported SSO protocols and identity providers]
2. 2Have your identity administrator configure the connection using the details at [PLACEHOLDER: exact console path/label, e.g. Settings > Security > Single sign-on].
3. 3Test with one account before requiring SSO workspace-wide, so a misconfiguration cannot lock everyone out at once.
4. 4Once verified, require SSO for all workspace members and remove any standing local accounts.

Discovery runs against the agreed boundary and produces a first-pass inventory.

1. 1Confirm the estate boundary and access are both complete — see the Getting set up topics above.
2. 2Trigger the scan from [PLACEHOLDER: exact console path/label, e.g. Workspace > New assessment].
3. 3Watch for confirmation that detectors have started against each connected source.
4. 4Expect a first-pass inventory within the timeframe agreed at kickoff.

You can see which sources have been read, which are pending, and roughly how far the run has to go.

1. 1Open the assessment's status view at [PLACEHOLDER: exact console path/label].
2. 2Check per-source status rather than a single overall percentage — one large repository can dominate an aggregate figure.
3. 3Note any source marked failed or skipped; these become candidates for the blind-spot list in the final report.

The inventory reflects the current boundary, and the change in scope is recorded rather than silently absorbed into the numbers.

1. 1Update the written estate boundary first, with the reason for the change.
2. 2Start a fresh assessment rather than editing the previous one's results in place.
3. 3Compare the new run's asset count against the old one with the scope change in hand — a count that moves is expected and should not be read as progress or regression on its own.
4. 4Record the method version each run was scored under; a score that moved because the method changed is a different fact from one that moved because your estate did.

A running scan stops without leaving the inventory in a half-written state.

1. 1Use the cancel control at [PLACEHOLDER: exact console path/label] rather than revoking access mid-scan, which can leave partial findings without provenance.
2. 2Confirm the assessment status changes to cancelled before revoking any credential provisioned for it.
3. 3If you cancelled to change scope, follow "Re-run discovery after a scope change" rather than resuming the cancelled run.

You can see which detector produced a finding, in which artefact and revision, and what evidence it matched.

1. 1Open the finding from the inventory list.
2. 2Check the provenance panel: the detector name, the artefact and revision, and the matched pattern or configuration value.
3. 3Check the inputs that moved the score and the weight each carried, not just the final number.
4. 4If something looks wrong, use the correction path in "Review disputed findings with your engineers" rather than dismissing it informally.

You know whether a tier moved because the estate changed, the method changed, or a correction was applied — and which of those it was.

1. 1Check the method version recorded on both runs first; a tier move across different method versions is not directly comparable.
2. 2If the method version is unchanged, check whether the asset itself changed — a configuration update, a new endpoint, a certificate renewal.
3. 3Check the correction history for the asset; an engineer confirming or overriding a finding during review also moves the tier.
4. 4Read the tier definitions rather than assuming: Acute, Elevated, Watch and Contained are fixed bands on the exposure score, not relative labels.

You can say what the estate's single number does and does not tell a reader, before it goes in a board pack.

1. 1Read the exclusions list before the score — the score is only a score of what was in scope.
2. 2Remember the aggregate is a weighted figure, not an average or a percentage of assets affected.
3. 3Track the tier distribution alongside the aggregate; movement between tiers is often visible before the aggregate shifts.
4. 4Cite the pilot figures only as an illustration of the method, never as a benchmark for your own estate.

A finding your team disagrees with is corrected in the record, with a reason, rather than argued about informally.

1. 1Open the finding and bring the evidence panel into the review session rather than describing it from memory.
2. 2Let the engineer confirm, correct or annotate the finding directly against the evidence.
3. 3Apply the correction to the asset record, not to the score in isolation, so the reasoning survives the next scan.
4. 4Leave anything unresolved as an open item rather than dropping it quietly.

A machine-readable cryptographic bill of materials for the scope you assessed, in a form your build or supply-chain tooling can ingest.

1. 1Open the assessment you want to export from.
2. 2Choose the CBOM export option at [PLACEHOLDER: exact console path/label and supported file format].
3. 3Confirm the export scope matches what you intend to hand downstream — a CBOM inherits the same estate boundary as the assessment it came from.
4. 4Store the export alongside your other supply-chain artefacts; it is a point-in-time record, not a live feed.

Internal audit or an external assessor receives the report, the standards mapping and the evidence trail in one package.

1. 1Confirm with audit what format and level of detail they expect before exporting — worth a five-minute conversation, not a guess.
2. 2Export from [PLACEHOLDER: exact console path/label].
3. 3Include the Evidence Ledger reference for the run alongside the report — see the Signal Log's Evidence Ledger panel for what that reference does and does not prove.
4. 4Record the method version on the export cover page so a reader in a year can tell which rules produced it.

A recipient can verify the attestation is genuine and current, independently of trusting the copy you sent them.

1. 1Generate the attestation from [PLACEHOLDER: exact console path/label].
2. 2Send the recipient the attestation reference, not only a PDF, so they can verify it themselves.
3. 3Point them to Attestation Lookup to check the reference against our record directly.
4. 4Reissue rather than edit if anything about the underlying assessment changes — an edited attestation is not the same record.

A named person can sign in to your workspace with the access level appropriate to their role.

1. 1Confirm your own role permits inviting others — see "Set roles and permissions for a new team member" if you are unsure.
2. 2Send the invitation from [PLACEHOLDER: exact console path/label], using their company email address.
3. 3Assign a role at the point of invitation rather than leaving it at a default.
4. 4Ask them to confirm sign-in before you rely on them for a review session.

A team member can see exactly the scope their job requires, no more.

1. 1Decide before inviting whether the person needs the whole estate or a scoped subset of it.
2. 2Choose the role at [PLACEHOLDER: exact console path/label and the exact role names available].
3. 3Review role assignments periodically, particularly after a reorganisation — access tends to accumulate rather than shrink on its own.
4. 4Remove access promptly when someone leaves the team or the company.

A credential you no longer trust stops working, without breaking scans that do not depend on it.

1. 1Identify every connection that uses the credential before revoking it — a shared credential across several sources will break all of them at once.
2. 2Issue a replacement credential first, then revoke the old one, to avoid a coverage gap.
3. 3Update the connection at [PLACEHOLDER: exact console path/label] with the new credential.
4. 4Confirm the affected sources show as reachable again before the next scheduled scan.

You can say what your plan covers — assessment frequency, seats and support level — without guessing.

1. 1Check the plan summary in the workspace at [PLACEHOLDER: exact console path/label, e.g. Settings > Billing > Plan].
2. 2Compare it against the current published tiers at /pricing; a plan agreed before a pricing change keeps its original terms unless you have agreed otherwise.
3. 3If a limit is unclear — seats, assessment frequency, data retention — ask through /contact rather than assuming the more generous reading.

You have the document your finance team needs, from a source you can point them back to.

1. 1Open the billing history at [PLACEHOLDER: exact console path/label, e.g. Settings > Billing > Invoices].
2. 2Download the invoice for the period you need.
3. 3If a past invoice is missing or a charge looks wrong, raise it through /contact with the invoice number rather than the amount alone.

Your plan changes, or your workspace winds down, on terms you agreed to in writing beforehand.

1. 1Confirm what happens to in-progress assessments and stored reports on a downgrade or cancellation before you request it — ask through /contact if this is not already written into your agreement.
2. 2Submit the change through [PLACEHOLDER: exact console path/label, or a named commercial contact if plan changes are handled outside the console].
3. 3Confirm the effective date in writing, since a plan change rarely takes effect mid-billing-period.

You can tell whether a low asset count reflects a small estate, a narrow scope, or a real gap in access.

1. 1Check the exclusions list first — a narrow estate boundary produces a low count by design.
2. 2Check every connected source shows as reachable; a failed connection produces silent under-counting rather than a visible error.
3. 3Compare against the documented detector coverage — some cryptography, such as runtime-only algorithm selection or closed appliances with no exposed configuration, is a known blind spot rather than a defect.
4. 4If none of the above explains it, raise it with your engagement contact with the assessment reference to hand.

The finding is either corrected with a reason recorded, or confirmed with the evidence that supports it — either way the record is accurate.

1. 1Do not dismiss it informally — open the finding and read the evidence panel with the engineer who disagrees.
2. 2Follow "Review disputed findings with your engineers" above to apply a recorded correction.
3. 3If the evidence itself looks wrong rather than the conclusion drawn from it, report it through /contact so we can check the detector.

A genuine security concern reaches the right people quickly, through a channel built for exactly that.

1. 1Stop, and do not attempt to test or exploit the issue further against our production systems.
2. 2Go to /security for our disclosure policy and the current channel for reporting a vulnerability.
3. 3Do not send us key material, credentials or customer data as part of a report, even as evidence — describe it instead.
4. 4If it is an active incident rather than a research finding, say so explicitly in your report.

You receive an export of the workspace data covered by your request, or a clear written explanation of why a specific item is withheld.

1. 1Read "What we hold, and what we never take" first, so your request names what actually exists rather than what you assume exists.
2. 2Send the request through /contact from a verified account holder or workspace owner address, naming the workspace and the scope of data you want.
3. 3Expect a written acknowledgement before the export itself. [PLACEHOLDER: turnaround time for a data-access request]

Your workspace data is deleted according to our published retention rules, and you know what that does and does not cover.

1. 1Read "Retention and deletion" first for what is deleted, what a backup cycle can delay, and what a legal hold can override.
2. 2Send the deletion request through /contact from a verified workspace owner address, stating whether you mean one assessment, one workspace, or the full account.
3. 3Ask for written confirmation once deletion completes, and keep it — it is your own record, independent of anything on our side.