Working demonstrators

The demonstrator connects to AWS, GitHub, Vercel, Microsoft Entra and Aikido Security. It records scan history, distinguishes passing, failing and unknown checks, and shows how a newly failing check can enter a remediation workflow. Some findings remain deliberately open so the demo does not suggest that every problem has been resolved.

The architecture distinguishes implemented paths from an illustrated future Vanta custom-test integration. This is not a production GRC platform or a substitute for an audit.

A connector per tool turns each platform’s records into one shape. Correlation and service-level logic only ever see that shape, so the same problem raised in two tools is linked, with the evidence for why, and service is scored separately for internal, consumer and partner audiences. No blended number hides a weak partner result behind a strong internal one.

Where a model suggests a likely root cause, it is labelled as AI-generated and unverified. The seed data deliberately leaves some signals unlinked, because a tool that links everything is worse than one that does not. A working “Connect a source” form maps a platform’s field names onto the common shape, with templates for ServiceNow, Jira, Zendesk, Freshservice, incident.io and Rootly.

Around that sit the operations views a service review needs, all computed from the invented records: a readiness check for accepting a service into live operation, links from incidents to a recent change with change failure rate and time to restore, a scorecard for invented suppliers, and a one-page review pack that prints to PDF.

This is not an integration with any organisation’s systems, and not a replacement for an ITSM platform. The connect form runs against a mock connector and never contacts a real system. Almost all of the data is invented. A few real records, captured once from sandbox Jira and Rootly accounts, are marked Live and are never correlated with the invented ones.

Building was the quick part. The useful result was what testing found: a default setting that quietly polluted the data, an automation that reported success while the email never arrived, and records that nobody owned.

The setup is a fictional member organisation with three membership programmes across five regions: 50 member companies, 120 contacts and 12 renewal deals worth £349,000 in total.

What went wrong, and what it showed

• A default setting polluted the data. HubSpot automatically created 50 nameless company records from the contacts’ email domains. They would have appeared in the data-quality report as members with no owner and no region. They were found and removed, and the setting was switched off.
• The automation succeeded, but the email never arrived. Every step reported success except one, and nothing on screen said so. The log showed “Previously unsubscribed from this subscription type”. The form’s consent checkbox recorded consent for one subscription type, and the email was sent under another. Each looked correct on its own.
• A business rule could not be written as stated. “Renewal within 90 days” has no direct filter in the workflow tool, which offers calendar periods or fixed dates. A fixed cut-off worked for the sandbox. A real build would use a calculated “days to renewal” property.
• Ownership was empty for every member. The planned account managers were never real users, so the data-quality check found every company unowned. Nobody owned the data, which is exactly when a CRM stops being trusted.
• The assistant met real guardrails. Some calls were refused for lack of permission, a deletion was blocked until a person approved it, and a reporting query needed permissions the connection did not have. Each time the work stopped and a person decided.

Building became quick. Ownership, consent settings and data quality did not. They are decisions someone has to make, and no tool makes them.