Open Property Data Association
Smart Property Data Trust Framework
Become a member Join a working group
    accepted

    Recruit later bounded-context working groups through a public campaign and simple sign-up

    Change note — 2026-09-10: ADR-0086 introduces the top-level Marketing toolkit and one canonical registry for its new recruitment assets. OPDA’s request to an organisation and that organisation’s member-facing invitation have separate voices; rich email previews and unsent CID-image EML drafts share the same content authority. The earlier outreach files below remain preserved historical sources. Signup fields, storage, human review and dispatch authority do not change. The development gate remains in force; all pages, including Marketing, are intended to be publicly readable at a separately authorised launch, with only per-page discussions authenticated.

    Change note — 2026-09-07: Client wall-clock timing no longer determines whether a working-group registration is stored: clock skew can make a legitimate submission appear too fast or future-dated. startedAt remains validated for compatibility, without changing the approved fields, privacy notice or stored record. With an empty honeypot, success follows the authoritative write; a populated honeypot retains the deliberate success decoy without storage. Validation, route throttling and bounded concurrency remain in place. This local correction does not claim deployment or change the decision’s accepted status.

    Deployment record — 2026-09-03: The AWS signup runtime is live in account 355653384628, region eu-west-2. The newsletter and working-group APIs, encrypted DynamoDB tables, KEYS_ONLY streams, shared publisher Lambda, encrypted SNS topic, integration queue and failure queue are deployed through opda-site; both stream mappings are enabled. The queue remains an integration handoff with no downstream email consumer. Safe direct Lambda diagnostics passed without creating records. Local frontend changes were not published as part of this infrastructure deployment.

    Change note — 2026-09-03: A shared post-persistence event boundary now follows the working-group and newsletter registers. Each form still returns success only after its own encrypted DynamoDB write succeeds. KEYS_ONLY streams feed one small Lambda, which publishes versioned record-reference events to one encrypted SNS topic and its SQS integration queue. Form fields are not copied into messages. The queue is a buffered integration boundary for an identified future consumer, not an active notification workflow; failed stream batches and failed topic deliveries are retained separately for diagnosis. This preserves the form and privacy contract while avoiding a database-and-topic dual write in the request Lambda.

    Change note — 2026-08-27: ADR-0078 moves the sole canonical signup journey to /join, its privacy notice to /join/privacy, and adds /accessibility. All three use a minimal standalone public-service shell rather than Knowledge Base furniture. The form remains at the bottom, keeps the approved fields and same-origin API, and requires successful JavaScript initialisation; the existing safe email alternative remains available. ADR-0079 removes the site-wide authentication gate instead of creating another route allowlist exception. The two earlier join route families remain absent without compatibility routing.

    Change note — 2026-08-27: The form no longer offers an undecided working-group choice; registrants select one or more of the six groups. The former combined cross-cutting contribution option is split into independent commercial-interest and public-interest choices. The collection, purpose, privacy notice, storage model and human-review boundary remain unchanged.

    Change note — 2026-08-27: An adversarial review replaced the oversized sticky handoff sequence with a natural-height comparison that keeps every domain meaning, moved the registration journey ahead of supporting modelling detail, and retained every approved field and contribution option. The form now fails safely without JavaScript: it cannot fall back to a query-string submission, it exposes an email alternative, and client enhancement validates the exact accepted response, times out stalled requests and associates errors with their controls.

    Change note — 2026-08-27: The join journey moved from /working-groups/join/** to /spdtf/working-groups/join/**, beneath its canonical Working groups owner. The old routes are absent without redirects, rewrites, aliases or duplicate pages. Join and privacy now use the shared Layout, breadcrumb, section navigation, global header and footer; the same-origin API, campaign information, form fields, review boundaries and submission behaviour are unchanged.

    Change note — 2026-08-21: The shared application header now carries a persistent “Join a working group” action to the unchanged canonical signup route. This adds a discovery path only; form scope, review, storage and access boundaries are unchanged.

    Change note — 2026-08-14: ADR-0071 now records the campaign operating plan, including LinkedIn publishing, selective trade-body outreach, sequencing and measures. This ADR remains the authority for campaign scope, the public signup experience, storage and review boundaries.

    Change note — 2026-08-13: Before the first publication, the sign-up design was simplified to match the operating need: accept a short form and store it for human review. The undeployed email-verification, Postmark, WAF, custom-origin and secret-management components were removed. The public form was subsequently extended to include Finance and Banking, while the social and trade-body recruitment campaign remains focused on the five groups without existing rosters.

    Context and Problem Statement

    The Finance and Banking Working Group began from a private roster supplied by OPDA. Equivalent contact lists do not exist for Conveyancing, Estate Agency, Surveying and Valuation, Property Data Services or Property Technology. ADR-0065 therefore calls for social-media recruitment and an explicit sign-up for those later groups.

    The campaign must explain the programme before asking someone to register. It needs a public, branded route that shows why connected domain models matter, how people contribute, and that technical or ontology knowledge is not required.

    The existing Astro site is statically built into a private S3 origin and delivered by CloudFront. A submitted form therefore needs a very small runtime boundary. Registration is an expression of interest, not automatic OPDA membership, standards authority, Teams access or SharePoint access.

    Decision Drivers

    • Reach practitioners beyond the existing Finance and Banking roster.
    • Explain the work in non-technical language before asking people to register.
    • Keep the form short enough to complete from a LinkedIn visit.
    • Store responses in one authoritative place rather than parallel spreadsheets and lists.
    • Keep acceptance, onboarding and Microsoft access subject to human review.
    • Minimise personal data and explain its use at the point of collection.
    • Reuse the existing AWS hosting and CI/CD architecture.
    • Keep the solution proportional to a simple expression-of-interest form.

    Considered Options

    • Option A — Private email lists. Wait for OPDA to obtain a roster for every context.
    • Option B — Third-party hosted form. Link to Microsoft Forms, Typeform or similar.
    • Option C — Email sign-up. Ask interested people to send an unstructured email.
    • Option D — Simple OPDA-hosted form. Add a public form to the existing Astro site and store each valid submission through API Gateway, Lambda and DynamoDB.

    Decision Outcome

    Chosen option: D — a simple OPDA-hosted form on the existing AWS site.

    1. Campaign scope and message

    The campaign combines a LinkedIn post with selective, one-to-one outreach to relevant UK trade and professional bodies. Both routes link to the same public page and recruit expressions of interest for exactly five later bounded-context groups:

    1. Conveyancing;
    2. Estate Agency;
    3. Surveying and Valuation;
    4. Property Data Services; and
    5. Property Technology.

    Finance and Banking continues through its existing participant process, but people may also register interest in that group through the public form. DBT Smart Data and the Interoperability Working Group are not advertised as additional property bounded contexts.

    The campaign explains that OPDA is creating the Smart Property Data Trust Framework as a governed family of connected domain models. People may contribute later by sharing authorised source material, explaining domain language and rules, reviewing model candidates, testing familiar outputs and challenging drafts.

    Participants are not being asked to understand ontologies, adopt AI or have technical knowledge. The campaign must not promise immediate access, membership, accreditation, voting rights, endorsement, publication of material or a release date.

    The original approved LinkedIn copy is preserved in docs/recruitment/2026-08-bounded-context-working-group-linkedin.md.

    Trade-body outreach asks an organisation to share the public opportunity with its network. OPDA does not request a member list, infer endorsement, bulk-add people or grant access through this route. Messages are sent individually to an official organisation-level contact or contact form. The original outreach assets are preserved below; ADR-0086’s registry is the authority for new Marketing toolkit variants:

    2. Public sign-up experience

    The sole canonical public route is /join, with the privacy notice at /join/privacy and the public accessibility statement at /accessibility. The former /working-groups/join/** and /spdtf/working-groups/join/** families are removed without compatibility routing. ADR-0079 makes the site publicly readable as one distribution invariant; the unchanged same-origin submission API retains its own validation and capacity boundaries.

    The three public-service pages use a minimal standalone shell with the official OPDA mark, registration, privacy, accessibility, Knowledge Base and organisation links. They do not render the Knowledge Base header, section navigation, breadcrumb, table of contents, previous/next navigation or article wrapper.

    The page explains the six selectable domain groups, the kinds of contribution OPDA needs and the sequence:

    1. the person registers their interest;
    2. OPDA reviews the expression of interest; and
    3. if accepted, OPDA sends onboarding and access separately.

    The form collects only:

    • first name and last name (a single “full name” field until 2026-09-17);
    • email address;
    • organisation;
    • role or area of expertise;
    • one or more of the six groups;
    • one or more contribution preferences;
    • where the person heard about OPDA (LinkedIn, interest group, colleague, friend, search engine or other, with a short free-text detail for “other”; added 2026-09-17); and
    • an optional, length-limited note about relevant experience or perspective.

    It does not collect telephone numbers, addresses, social profiles, demographic or special- category data, property or customer data, evidence files, or links to evidence. A required acknowledgement makes clear that this is an expression of interest and permits OPDA to contact the person about selected groups. There is no newsletter or marketing consent.

    3. Review and access

    A human acting for OPDA reviews every expression of interest. The public service does not create Entra guests, add Team members, create SharePoint groups or folders, send invitations, or assign standards decision rights.

    Generic-provider addresses are permitted at sign-up and may later be invited to Teams. The company-domain restriction applies only if SharePoint evidence access is later provisioned.

    4. Hosting and storage

    The existing AWS architecture in ADR-0038 and ADR-0040 is extended as follows:

    • the static Astro campaign page and privacy notice remain in S3 behind CloudFront;
    • a cache-disabled CloudFront behaviour for /api/working-group-interest* targets an Amazon API Gateway HTTP API in eu-west-2;
    • one small Node.js Lambda accepts POST /api/working-group-interest; and
    • one encrypted, on-demand DynamoDB table in eu-west-2 stores each expression of interest.

    After the authoritative write, that table and the separate newsletter-subscription table expose KEYS_ONLY DynamoDB streams to one shared, 128 MiB Arm Lambda. It publishes a versioned event containing only the stream event identifier, event type, timestamp, record kind and record key to an encrypted SNS topic. One encrypted standard SQS queue subscribes to that topic as a durable, reference-only integration handoff. A separate encrypted failure queue retains exhausted stream batches and failed topic deliveries. There is no provisioned capacity, VPC, NAT gateway, FIFO queue, Step Functions workflow or always-on consumer.

    The shared publisher emits an event for a newly stored expression of interest, and for a new or refreshed newsletter subscription. It ignores working-group record updates and every removal, including TTL expiry. Delivery is at least once and unordered. A future consumer must deduplicate on the stable stream event identifier. Until such a consumer is implemented, the integration queue does not send email or change either authoritative record.

    Each accepted request receives a generated registration identifier. The table stores the form fields, status received, timestamps and active privacy-notice version. Request bodies, email addresses, raw IP addresses and user-agent strings must not be written to application logs.

    5. Boundary validation and basic abuse controls

    The Lambda accepts JSON only, enforces a 16 KB body limit, rejects unknown fields, HTML, control characters, invalid email syntax, excessive lengths and values outside the explicit group and contribution allowlists. A populated hidden honeypot receives the ordinary success response as a deliberate bot decoy without storing data. The client startedAt value remains structurally validated for compatibility but is neither persisted nor compared with the server clock to gate storage: client timing alone must not silently discard a valid submission. Every otherwise valid request with an empty honeypot receives success only after its authoritative write completes. API Gateway applies a low route throttle, Lambda has bounded concurrency, and the table is on-demand. There is no minimum or maximum completion-time gate based on client wall-clock values.

    This design intentionally has no email verification, confirmation route, Postmark call, WAF, custom API hostname or runtime secret. These can be reconsidered if observed abuse or an operating requirement justifies them.

    6. Privacy and retention

    The form links to /join/privacy, which names OPDA as controller, explains the recruitment and administration purposes, lists the information collected and AWS/Microsoft service relationships, states retention and provides smartdata@openpropdata.org.uk for rights requests.

    Expressions of interest that are declined, withdrawn or not progressed are retained for no more than six months. Accepted participant records are retained for the working group’s duration plus 12 months unless a separately documented legal obligation applies. DynamoDB TTL is enabled for the initial six-month period; accepted records require a deliberate retention update in the later operating process.

    The optional note warns against confidential, personal, customer, property-transaction or special-category information. Registration data is operational recruitment data and must not enter the AI evidence or ontology-building corpus.

    Consequences

    • Good, because later groups can recruit beyond unavailable email rosters.
    • Good, because the public explanation and form use the OPDA domain and design system.
    • Good, because one encrypted register replaces parallel spreadsheets and exports.
    • Good, because the runtime has one route, one write operation and no secret or email dependency.
    • Good, because stored submissions expose one reusable, reference-only integration boundary without placing names, email addresses or other form fields in SNS or SQS.
    • Good, because streams avoid the partial-failure state created by writing the database and publishing an event independently in the request Lambda.
    • Good, because human review remains the acceptance and access boundary.
    • Bad, because OPDA still owns a small public runtime and a personal-data register.
    • Bad, because an unverified address can be mistyped or deliberately submitted by another person.
    • Neutral, because obvious automation is filtered but determined abuse may require stronger controls later.
    • Neutral, because the SQS queue is a durable handoff rather than a complete downstream workflow until an authorised consumer is defined.

    Confirmation

    This decision is confirmed when:

    • the campaign names only the five later contexts, while the form also accepts Finance and Banking, and links to the canonical public route;
    • trade-body outreach uses approved assets and never requests a member list;
    • anonymous visitors can access /join, /join/privacy, /accessibility and the submission API without an authentication redirect, while all four former join/privacy URLs reach an unrewritten origin 404;
    • the service exposes one POST route and stores one validated record per accepted submission;
    • automated tests cover invalid fields, oversized bodies, harmless honeypot decoys, ahead/behind client clocks, fast and long completion, and success only after storage (including failures);
    • DynamoDB is encrypted, on-demand, TTL-enabled and the Lambda can only write to its table;
    • both submission tables expose KEYS_ONLY streams to one shared publisher, SNS topic and SQS handoff, with bounded retries and an encrypted failure queue;
    • published messages contain record references and event metadata but no submitted form fields;
    • no Teams or SharePoint access is provisioned by the public service;
    • keyboard and reduced-motion behaviour remains usable; explanatory and privacy content remains readable before enhancement, the form cannot fall back to a GET request, and successful JavaScript initialisation enables the submit control;
    • make test and make build-data pass; and
    • infrastructure and static pages deploy through the existing CI-only AWS workflows.

    Pros and Cons of the Options

    Option A — Private email lists

    • Good, because it reuses the Finance and Banking process.
    • Bad, because OPDA lacks the five required rosters.

    Option B — Third-party hosted form

    • Good, because it is quick to publish.
    • Bad, because it adds a provider and fragments the participant record.

    Option C — Email sign-up

    • Good, because it needs no application runtime.
    • Bad, because unstructured messages require manual transcription and create inconsistent records.

    Option D — Simple OPDA-hosted form

    • Good, because it gives one branded journey and one authoritative register.
    • Bad, because OPDA owns the small runtime, privacy and retention process.

    More Information

    ← Back to ADR Corpus  |  View source

    ADRs are MADR-format architecture decisions. A superseded ADR is replaced by a later record rather than edited in place.

    Comments

    Loading comments…