Resources / Sample reference pack

Synthetic reference

Sample system project deliverables

Inspect five files for one inquiry-to-CRM project: the brief, architecture, field dictionary, acceptance test cases and runbook. Use them to assess what a defined implementation should include.

Open the project files See the sample record

From specification to handover

The reference pack defines the work, the expected behavior and the instructions needed to operate it. Records and IDs are fictional. Fixtures show expected behavior and have not been run against a live CRM or connector.

DefineBrief, architecture and field rules
CheckSix expected acceptance cases
HandoverOperating and recovery notes

Download and inspect

Five files, one reference project

Open any file without sharing an email address. All examples describe one fictional SaaS inquiry-to-owner system.

01 / ScopeSynthetic reference

Project brief

Purpose, accepted input, responsibilities, dependencies, release gates and explicit scope boundaries.

reference-project-brief.txt

Download the brief

02 / ArchitectureSynthetic reference

System map

The full path, a log of every processed request, the review queue and the recovery steps for failed writes.

capture-to-owner-map.png

Download the architecture

03 / DataSynthetic reference

Field dictionary

Types, source ownership, permitted updates, examples and validation rules for the reference contract.

reference-field-dictionary.csv

Download the field dictionary

04 / AcceptanceSynthetic reference

Six acceptance test cases

New inquiry, repeated event, existing customer, invalid email, ambiguous identity and unknown write outcome. Includes input and expected destination state.

reference-acceptance-fixtures.csv

Download the fixture matrix

05 / OperationsSynthetic reference

Handover runbook

Monitoring, review ownership, reconciliation, controlled replay and change approval. Includes a release checklist.

reference-handover-runbook.txt

Download the runbook

The project boundary

One inquiry should reach an accountable next step

Use this synthetic reference for planning and review. Check every assumption against your own systems before a live build. For republication or redistribution, contact andrii@agitechnologies.io.

This vendor-neutral reference models a founder-led B2B SaaS team. A real build must map these application fields and rules to its actual forms, CRM and automation tools.

Synthetic project / v1.0

Inquiry-to-owner infrastructure

Accept a valid demo request, resolve the account and contact, preserve an existing customer owner, and create the agreed follow-up task. Hold invalid or ambiguous records with a visible reason.

Input: One versioned demo request
Expected complete state: Linked account and contact, named owner, follow-up task and receipt
Outside this reference: Marketing enrollment, lead sourcing and revenue forecasting

A worked record

From inquiry to expected CRM state

Test case A01 is a valid new inquiry that should be accepted. These are its expected values.

A01 / Synthetic input

A request with a stable identity

The source submission ID stays stable across delivery attempts. The email and company domain are fictional examples.

capture_id: CAP-1001
source_event_id: SRC-1001
work_email: alex@nova.example
company_domain: nova.example
inquiry_type: demo_requested

A01 / Expected state

An owner can act on the inquiry

The complete receipt requires a destination readback: linked records, the agreed owner and exactly one follow-up task for this capture.

processing_status: COMPLETE
crm_account_id: ACC-201
crm_contact_id: CON-301
owner_id: OWN-02
followup_task_id: TSK-401

Full system map

Follow the inquiry through each decision

The success path ends with checked destination records. Invalid input, uncertain matching and uncertain writes have separate routes.

Five stages take a synthetic inquiry through capture, validation and identity checks, owner assignment, CRM actions and a destination receipt. Uncertain inputs and writes go to review or reconciliation. — Reference design. The receipt is complete only after the expected destination records, owner and task are checked.

Acceptance expectations

Success and failure both need a defined state

The CSV carries the full input, existing records and checks. Before a production release, run these test cases in the chosen environment and check the destination records.

Success and failure both need a defined state
Fixture	Input condition	Expected handling	Required check
A01	New valid inquiry	COMPLETE	One account, contact association, owner and follow-up task; saved receipt
A02	Previously completed source event	SUPPRESSED_REPEAT	Reference the original receipt; create no extra record or task
A03	Existing customer account	COMPLETE	Preserve customer status and OWN-01; one task for the new inquiry
A04	Invalid email value	VALIDATION_REVIEW	No CRM write; a review item explains the rejected field
A05	Two plausible account matches	IDENTITY_REVIEW	No CRM write; resolve identity before a controlled replay
A06	Write request times out	PENDING_RECONCILIATION	Record outcome as unknown; confirm destination state before any repeat write

Operating decisions

A delivered form is only the start of the path

An accepted capture means the submission was persisted. COMPLETE means the required destination state was checked.

Use the source event ID to suppress repeated delivery, and record a separate operation key for each external side effect. A key is a design requirement: implement and test it in each build.

An uncertain match or missing active owner goes to review before CRM changes. A timeout after a write is different: the write might have committed. Reconcile the destination and saved operation state before deciding whether a replay is safe.

The approved inquiry purpose and captured permissions stay separate from marketing eligibility. The reference does not enroll contacts in campaigns or treat a form submission as a qualified opportunity.

Technical references

The recovery rules have a clear basis

The workflow is AGI Technologies' reference design. The references support its retry distinction and use of documentation domains.

IETF RFC 9110, section 9.2.2
HTTP retry guidance distinguishes repeat-safe semantics from uncertain writes. The reference requires reconciliation before retrying an unconfirmed create action.
IANA reserved domains
Reserved documentation domains keep every example fictional.

Apply it to a defined scope

Choose the service for your system boundary

Use the reference to describe the inputs, tools, operating model and failure case that your project needs to address.

Startup infrastructure

Define the first complete path

For founder-led, first sales-team or trial-led SaaS requirements, scope capture, identity, CRM, owned actions and handover together.

Review startup infrastructure

Existing HubSpot environment

Repair CRM and RevOps handoffs

For an existing HubSpot system, review lifecycle definitions, record associations, routing and integrations against the way the team works.

Review HubSpot and RevOps services

Website, CRM and measurement

Connect the inquiry handoff

For a team with an existing website and stack, connect forms, CRM, automation and measurement with defined field ownership and validation checks.

Review martech infrastructure

Scope the next step

Define your project's input and terminal state

Share the current source, destination tools, decision owner and the failure you need to prevent. The reference pack can help describe the scope before discussing implementation.

Book a 30-minute call