Geelong Engineering Workshop · Leadership and investor briefing

Four days to make StockLive easier to explain, design and grow

The workshop aligned the product, business model and engineering direction around one shared view of StockLive.

Geelong14–17 September 2026Four workshop days

This briefing explains what the Geelong workshop achieved and what still needs to happen. It gave product, design, engineering and leadership one shared explanation of StockLive. Over four days, the group compared different mental models, tested them against real workflows and integrations, and made a series of choices about the product’s core business records. The most important result is a simpler direction centred on the Lot, supported by clearer ownership across Sale, Auction, Catalog, HubSpot and Nexlot. The workshop also exposed unfinished work instead of hiding it. That distinction matters for leadership and investors: the week created decision quality and a common foundation, but it did not by itself ship the new architecture or prove a financial return. The following slides separate the decisions, the expected value and the remaining delivery risk.

Why the workshop mattered

Growth had created a coordination problem

Different parts of the business used different models for the same customer journey.

Slower decisions

Repeated discovery

Higher delivery risk

StockLive has grown through real customer needs, integrations and operational workflows. That growth created useful capability, but it also left different groups with different explanations of the same journey. Terms such as Sale, Consignor, Consignment, Listing, Lot and Assessment did not always mean the same thing to everyone. Ownership was sometimes inferred from existing tables or screens rather than agreed as a business rule. When that happens, every new design or integration begins with rediscovery. Teams reconstruct why the system behaves as it does, and new work can accidentally create a second source of truth. The workshop treated this as a coordination and delivery risk. The aim was to reduce ambiguity before the next wave of product work. The evidence is practical: shared definitions, explicit boundaries, recorded decisions and a visible list of work that still blocks implementation.

The workshop method

Four stages produced one shared direction

Align

Surface assumptions and disagreements.

Architect

Agree identity, ownership and boundaries.

Apply

Test the model against real workflows.

Converge

Close decisions and expose remaining work.

The workshop followed a deliberate progression. On the first day, the group made its mental models visible. Whiteboards and scratchpads captured where people agreed and where familiar words concealed different meanings. On the second day, the discussion moved to identity, authorization, dashboard entry and the lifecycle of a Lot. The third day tested the emerging model against Appraisal, forms, Auction, Catalog and the Nexlot integration. The fourth day focused on convergence. The team reviewed the capability map, closed decisions on naming, ownership and sources of truth, and left genuinely unresolved areas open. The final model did not come from one diagram or one person’s proposal. It emerged by testing competing ideas against business workflows and the existing system. The result is a shared direction with an evidence trail, not a claim that every implementation detail is finished.

The central outcome

Lot became the central business record

One Lot connects what is being sold, its appraisal and declaration, the form rules that shaped it, and the bids made against it.

Salebusiness source

Auctionselling workflow

Catalogseparate sale type

Lotcentral record

Appraisal

Declaration

Form rules

Bid

The central domain decision is that Lot becomes the durable business record around which the selling workflow is organised. In plain language, a Lot holds the coherent story of what is being offered and what happens to it. Appraisal and Declaration belong directly to the Lot. Their form rules remain separately versioned so historical data does not lose its meaning when a form changes. Bids also belong directly to the Lot and to the person bidding. Sale remains the business source of truth during the transition. Auction supports the auction workflow, while Catalog remains a separate type of Sale with different behaviour, including advertising and Buy Now concepts. This diagram is intentionally simpler than a database schema. It shows the business relationships leadership should understand. It does not claim that the target model has already replaced the legacy system. It records the direction against which design, migration and implementation work can now be evaluated.

Disciplined simplification

Three extra layers left the target model

Consignment

Listing

Item

Their responsibilities move to clearer concepts. That reduces duplication without pretending the legacy code has already disappeared.

Simplification was another material outcome. During the week, the team tested whether Consignment, Listing and Item each deserved to remain a separate target entity. The final direction removed all three. Consignment had become an extra layer around work that now belongs on Lot or within the participation relationship. Listing was explored as a presentation and integration boundary, but the group later decided that Bid should connect directly to Lot and that Nexlot can integrate through Lot or AuctionLot. Item had not been defined strongly enough as a separate Exchange concept. Removing these layers does not mean deleting legacy code immediately. It means the future model will not reproduce complexity simply because the current system contains it. This creates a clearer migration target: each responsibility needs a real business owner and lifecycle.

Clear sources of truth

Each system now has a clear job

SaleBusiness source of truth during the transition.

HubSpotSales leads and Organisation creation and management.

AuctionSelling workflow derived from Sale, without competing with it.

NexlotLot and Bid exchange, with incomplete records held for review.

Audit recordAppend-only lifecycle history through PaperTrail and Jira.

The workshop also clarified where important information should originate. Sale remains the business source of truth while the new Auction concept is introduced. Auction can mirror or derive from Sale, but it must not become a competing record that diverges from it. HubSpot becomes the source of truth for sales-lead information and for Organisation creation and management flowing into StockLive. That makes a separate StockLive Booking model unnecessary for the target direction. Nexlot exchanges Lot and Bid information through an explicit boundary. If provider data is incomplete, the system should stage or quarantine the record rather than attach uncertain information to a Lot. Lifecycle history will be append-only, using PaperTrail and Jira as the practical audit evidence. One detail remains open: the exact allocation of lifecycle states between Lot and Auction. The history principle is settled, while the state ownership still needs a final contract.

Expected business value

Clear boundaries create safer growth

Clearer workflowsCustomer and staff journeys can use the same underlying concepts.

Safer migrationLegacy and new models have an explicit coexistence rule.

Faster designTeams can work from agreed boundaries instead of rediscovering them.

Stronger evidenceAudit history and integration gaps remain visible and reviewable.

Expected benefits from the agreed direction. These outcomes have not yet been measured.

These decisions create business value by reducing uncertainty around future work. A clearer domain model allows customer-facing and internal workflows to share the same concepts instead of translating between competing versions of the business. The Sale and Auction coexistence rule lowers migration risk because it establishes which record remains authoritative. Separately versioned form rules protect historical interpretation as forms evolve. Explicit Nexlot staging and replay expectations reduce the chance that incomplete external data silently corrupts the product model. Contextual authorization provides a foundation for showing the right actions to the right person within the right Organisation. These are expected benefits, not results that the workshop measured. Leadership should judge the next phase by evidence: whether design starts with fewer unresolved questions, whether implementation avoids duplicate truth, whether integrations become easier to reconcile, and whether delivery teams can explain ownership without reopening the same foundational debate.

Decisions closed in Geelong

The team left with specific commitments

Core record

Lot owns the central product story.

Bidding

Bid belongs to Lot and a Bidder.

Participation

Participant is the product view. Sale Organisation is the backend model.

Responsibility

People own Lot and Appraisal work. Organisations participate in Auction and Catalog.

Forms

Appraisal and Declaration rules stay separate and versioned.

Access

Role, permission and Organisation context work together.

The strongest outcome is the specificity of the decisions. Lot is not simply another table. It is the central product record. Bid belongs to a Lot and to a Bidder, who is a user in StockLive. For product and leadership conversations, an Organisation taking part in a Sale is a Participant. The backend model for that relationship is Sale Organisation. Its name is settled, although the precise permissions carried by that relationship still need to be defined. Lot and Appraisal work normally have a named person responsible for them. Auction and Catalog sit at the top level and relate to participating Organisations. Appraisal and Declaration use separate, versioned form rules tied to livestock type. Access decisions consider role, permission and Organisation context together. These commitments give design and engineering a shared basis for the next work. They also make disagreements visible when a future proposal contradicts the workshop direction.

Remaining questions and delivery risk

The workshop also made the unfinished work visible

Backend, API and CES ownership and contract
Minimum evidence required before build begins
Nexlot backfill evidence and reconciliation
Lifecycle states split between Lot and Auction
Participant permissions through Sale Organisation
Final rules for Buy Now
Production operations and observability
Formal ADRs and 30 / 60 / 90 ownership

A credible briefing needs to show what remains open. The boundary between the backend, API and the service referred to as CES still needs a clear owner and contract. The team has not yet agreed the minimum evidence required before design or build can be called ready. Nexlot backfill still needs source payload evidence, reconciliation behaviour and proof that incomplete records can be recovered safely. The method for recording lifecycle history is settled, but the exact state split between Lot and Auction is not. Participant is the product term and Sale Organisation is the backend model, but the permissions that relationship grants still need definition. Buy Now was named but not specified in enough detail for implementation. Production operations, observability, incident response and rollback were not assessed during the workshop. Finally, many decisions are ready to become ADRs, design work and owned 30, 60 and 90 day outcomes, but those handoff records are not complete.

The handoff

A shared direction now needs delivery evidence

01RecordPromote accepted decisions into ADRs.

02DesignTurn stable boundaries into customer and staff workflows.

03BuildSequence implementation behind the remaining evidence gates.

04MeasureShow less rework, clearer ownership and safer change.

The workshop replaced shared assumptions with a shared starting point.

The workshop created a stronger starting point, and the next phase must turn that clarity into evidence. First, the accepted architecture decisions should be recorded as durable decision records with rationale, consequences and owners. Second, product and design can translate the stable boundaries into customer and staff workflows, using Participant as the human-facing concept and keeping backend terminology out of the experience. Third, engineering plans can sequence the new model and integration work behind the remaining evidence gates, especially Nexlot and the backend API boundary. Fourth, leadership should expect measurable proof that the new direction improves delivery. Useful evidence includes fewer repeated architecture discussions, clearer ownership of work, safer reconciliation of external data, faster design decisions and reduced rework. The week did not finish the transformation. It did something necessary before that transformation can succeed: it replaced a collection of private assumptions with one shared, reviewable direction and an honest account of what remains.

Arrow keys, Space, Page Up and Page Down

1 / 10