LASP discovery starts below the application layer

Set the provenance before the architecture

The public material identifies a land-asset sales service with assets in preparation, marketed properties, sales history and unsolicited bids. It says little about the internal application, integrations or records implementation. Those gaps remain discovery questions.

Start the evidence register with claim, source URL, retrieved UTC, confidence and test required. Mark every inferred workflow as a hypothesis. This prevents a plausible diagram from becoming an accidental claim about a government system.

Write the service state before naming a product

A workable first state model is identified → assessed → prepared → approved → marketed → offer/bid → decision → sale/transfer → settlement → closed. Interview the service owner against each transition. Record the actor, prerequisite, information created, delegated decision, exception path, system of record and recordkeeping trigger.

Use stable event names and identifiers. A property reference, bid reference and settlement reference may describe different objects. Joining them through display text will eventually fail. The discovery pack should show the candidate keys and the collisions found in sample exports.

Inspect DNS, TLS, IIS, identity and data paths first

When authorised access is available, capture the request path before changing it. For an on-premises SharePoint candidate, record Resolve-DnsName host, Test-NetConnection host -Port 443, Get-WebBinding, the certificate thumbprint from Cert:\LocalMachine\My, Get-SPAlternateURL, the farm build and the SQL connection target. Redact hostnames and account names in the public pack.

A failed portal may still contain the only executable description of field rules, document templates, security groups and exception screens. A bounded recovery environment can expose that evidence. The recovery has an exit date and no route to unreviewed production writes.

Map compliance to fields and events

PRIS, WA information classification and State Records Office guidance create concrete questions. Which fields contain personal information? What collection purpose is recorded? Which role can disclose a valuation or bid? Which transition creates a State record? Which audit event proves the approval?

The WA Auditor General reported broad sharing, incomplete DLP coverage, guest-control weaknesses and logging gaps across audited Microsoft 365 tenants. The discovery should therefore test effective sharing and audit results with synthetic records. A policy screenshot supplies configuration evidence only.

Build one proof slice across the hardest authority path

Select a transaction with external identity, restricted data, approval and a downstream record. Implement the smallest vertical slice that can create a synthetic asset, invite an approved external persona, submit a bid, deny an unrelated persona, record the decision and emit the required audit and recordkeeping evidence.

Capture the identity object ID, role or relationship, Dataverse table or alternative data object, request ID, audit operation and resulting record identifier. A successful screen matters less than the complete event trail and the prohibited 403 result.

Score candidate architectures against the same proof

Power Pages with Dataverse, a model-driven internal app, SharePoint Online with Power Platform, a custom Azure application and a hybrid transition remain candidates. Score each one against the same identity, record-isolation, document, workflow, search, integration, accessibility, support and cost tests.

Record rejection triggers. If relationship-based row access cannot be expressed or tested safely, stop the portal option. If a custom application adds no material capability over configured Dataverse, record the avoidable engineering burden. The matrix makes the architecture decision reviewable.

Produce a pricing-grade handoff

The discovery exit contains an object and event model, source inventory, identity map, compliance traceability, dependency graph, option score, proof results, migration populations, acceptance matrix, assumptions, exclusions and unresolved risks. Every work package names its input population, completion rule and evidence.

That package supports fixed delivery tranches where quantities and acceptance are stable. Volatile integrations or inaccessible data remain capped investigations. The tender response can then price known work instead of hiding unknowns in contingency.

Keep the research boundary visible

This note demonstrates a method. It supplies no DPLH configuration finding, supplier criticism, outcome claim or saving estimate. Public sources can shape the questions; only authorised discovery can answer them. Review the source register when the tender, service material, WA policy or Microsoft behaviour changes.