Joey King
Selected workCase study

Automation audit & retention platform

ProductionIn production since about May 2025

Context

Automation teams ran internal workflows that acted on real systems. During the investigation of one automation incident, the team found that the application logs that would have explained what happened had already expired, so they couldn’t reconstruct it.

This wasn’t an audit finding or a compliance failure. It was an operational gap in traceability and retention that any team running automations could run into.

Problem

Teams needed a durable, consistent way to record what their automations did and to find that history later, without every team building and running its own retention solution.

My role

My team lead raised the traceability problem after the incident. I turned it into a research spike, and from there I owned the work in practice:

  • discovery with the analytics team and prospective users
  • the event schema and the MVP
  • presenting the design for architecture approval
  • the work plan, features, and stories
  • implementing, testing, and releasing the service
  • documentation, onboarding, and integration support
  • diagnosing production issues
  • later, retrieval APIs and the user interface

This was technical and project ownership, not people management or enterprise-architecture authority. The analytics team owned the downstream event consumer and the Snowflake warehouse.

Constraints

  • Build on what teams already had. Spring Boot, Kafka, and an existing analytics path into Snowflake, rather than a new data platform to create and operate.
  • Architecture review. A shared architect needed to review and approve the design.
  • A critical dependency owned by another team. The consumer and warehouse that made retention possible belonged to the analytics team.

Key decisions

A common contract with room for real differences

I defined a common event schema with required fields, working from what prospective users needed. Stakeholder feedback added a flexible field for context that didn’t fit the shared schema. The service enforced what every record needed without taking responsibility for every application’s domain-specific data.

More than one way in

Teams could submit events through an API, publish them to Kafka, or use reusable integrations I built for Spring Boot, Go, and C#, which recorded the requests going to and from the host application. Supporting both paths kept the platform open to teams moving toward event-driven designs without shutting out applications that needed a simpler integration.

These two choices are the ones I’d defend as most clearly mine: together they balanced consistency with practical adoption.

Reuse the retention path instead of building one

Instead of standing up a separate retention store, the service fed the existing analytics pipeline. That delivered seven-year retention while keeping warehouse ownership with the team already responsible for it.

Delivery and adoption

The ingestion service reached production around May 2025. The main obstacle to adoption was visibility, not resistance, so I scheduled demonstrations and Q&A sessions, published onboarding material, and stayed available while teams integrated.

The platform then grew beyond ingestion. I added retrieval endpoints and a React and TypeScript interface with pagination, date filtering, and limited role-based access, which reached production around May 2026. Separately, a cohort of three high-school interns spent four weeks building a UI prototype on dummy data under my direction.

Two problems after release:

  • An oversized event. A consuming team hit errors because an audit event exceeded Kafka’s event-size limit. I traced the failure to that limit and explained the change the team needed to make.
  • Production data in the wrong place. While finishing the production UI, we found that production events were being routed to a test warehouse downstream, so the UI couldn’t retrieve them. Completion waited while the analytics team corrected the routing.

Outcome

  • The ingestion service has been in production since about May 2025, with the retrieval UI added around May 2026. It was still running when I left.
  • About four teams and ten automation applications had integrated by May 2026. These counts are approximate, from my own notes.
  • Records are kept for seven years through the analytics team’s Snowflake path.

What I learned

  • Adoption follows fit. Offer integration paths that match how teams already work, make the shared contract flexible enough for legitimate differences, document it clearly, and create visibility on purpose.
  • A critical downstream dependency is part of the project. I’d set recurring technical checkpoints with the analytics team and validate the full production data path early. That likely would have caught the routing problem before it delayed the UI.
  • Start the demos early. I’d begin the demonstration and Q&A cadence at launch instead of waiting for visibility to become the adoption problem.