Architecture boundary
Source-of-truth boundary
The portal remains the external source. The internal database stores versioned observations and provenance rather than silently replacing portal history.
Browser integration workflow
Keep login-only property, permit, planning, inspection, or tender portals synchronized with a governed database when the source offers no usable API.
Illustrative implementation pattern. These are real examples of working operating-layer patterns. What can be implemented in practice depends on authorized access, platform terms, data quality, security requirements, client participation, and agreed human-approval controls. Tools named in these patterns are possible components, not required products. Property, planning, tax, valuation, safety, biometric, engineering, and legal outputs require appropriate qualified review.
Why this workflow matters
Some important systems remain accessible only through a browser. The portal remains the external source, while the internal database needs normalized observations, provenance, source identifiers, last-seen dates, and change history without treating one failed run as a deletion.
Architecture boundary
The portal remains the external source. The internal database stores versioned observations and provenance rather than silently replacing portal history.
Reference layer
These sources and tools are selected according to authority, permission, technical fit, security, and client ownership.
Dedicated client-owned portal accounts and an approved secrets manager.
Chrome or Chromium with Playwright for approved navigation.
Permitted screenshot, HTML, source-file, OCR, or vision capture.
PostgreSQL or Teable with portal, query, listing, snapshot, observation, document, run, and exception records.
Object storage for permitted source files and evidence.
n8n, Temporal, or a job queue for scheduling, retry, timeout, and alerting.
Slack, Teams, or email for accountable exception alerts.
Ten-stage operating path
Each stage establishes a distinct decision, record, handoff, or approval boundary. Exceptions remain visible instead of being silently forced through the process.
Authorize the account, purpose, schedule, permitted actions, and platform terms.
Navigate to the saved search or approved page.
Wait for defined page-ready conditions rather than relying on a guessed delay.
Capture source ID, fields, files, URL, timestamp, and evidence.
Compare the observation with the previous snapshot.
Classify new, changed, relisted, withdrawn, or uncertain records.
Validate required fields and duplicate rules.
Write approved changes as versioned database events.
Escalate CAPTCHA, layout change, access failure, or ambiguous changes.
Monitor run health, freshness, completeness, and portal changes.
Required data layer
The implementation boundary should name each required record, relationship, source, status, permission, and owner before automation is introduced.
Portal
Query
Listing
Snapshot
Field Observation
Document
Run
Exception
Source Identifier
Last-Seen State
Authority, source quality, permissions, uncertainty, and consequential external actions remain explicit throughout the workflow.
Acceptance measures
Acceptance measures test the reliability and governance of the workflow. They are evaluation criteria, not promised performance results.
Typical starting engagement
This is planning guidance for a bounded first implementation, not a quote. The Blueprint confirms systems, access, data condition, responsibilities, exclusions, acceptance, timing, and fixed price.
Workflow assessment
Confirm the current records, sources, permissions, owners, exceptions, approval points, and acceptance measures before selecting automation or AI tools.