ENTERPRISE INTELLIGENCE / SYSTEMS & DATA

Make accountability
visible.

I connect separate assurance programs into a shared view of evidence, owners, and the next responsible action.

Owners can see what to prepare. Reviewers can see what awaits acceptance. Leaders can trace a portfolio total to the dependency behind it. Keeping submitted and accepted evidence separate makes those handoffs visible.

Assurance Navigator public demo · 805 synthetic requests. The private Bedrock/Claude workbench and separate Claude Code evidence review are described below.

Current synthetic Assurance Navigator: portfolio totals, owner actions, reviewer queue, and a prepared evidence investigation
Current application screenshot · Fully synthetic organizations, owners, and requests.
MY CONTRIBUTION / ASSURANCE NAVIGATOR

A total should lead
to the work behind it.

I built Vanta and Hyperproof API integrations, individual program dashboards, and a combined enterprise view. Snowflake data work, Jira, and Salesforce connections supported the broader operating picture.

Connect the sources

Bring records from separate programs into a common model while preserving their original status and business context.

Preserve the handoff

Keep submitted evidence separate from acceptance. Returned, in-progress, and unstarted requests remain visible as owner work.

Show who can act

Connect counts to owners, deadlines, exceptions, and review queues so a status can lead to a responsible next step.

The design decision: report workflow states separately instead of flattening them into a single completion number. Workflow progress still does not establish control effectiveness.

Source records feed a normalized request model, which supports enterprise, program, owner, and request views
PUBLIC DEMONSTRATION / FOLLOW THE RECORD

From a portfolio count
to the next action.

The public application uses 805 fictional requests across 12 platforms. Its views use the same request set, so you can inspect how a count relates to a particular owner and record.

  1. PortfolioSeparate accepted evidence, review queues, and owner action.
  2. OwnerInspect workload and the requests assigned to an owner.
  3. RequestOpen a record from the evidence pipeline.
  4. Evidence reviewFollow the prepared access-review investigation into missing evidence and the next action.

Fully synthetic public example. The prepared investigation has fictional artifacts and analyst decisions. These records do not establish production outcomes or live integrations.

SEPARATE IMPLEMENTATION / APPLIED AI

Bring evidence and requirements
into the same review.

I developed an AI workbench using AWS Bedrock and Claude, semantic retrieval, and persistent context. It brings evidence and requirement context together so potential gaps can be investigated against their sources.

The Bedrock/Claude workbench

The workbench is a separate implementation. Its broader code and evidence are available for discussion through a walkthrough request; they are not the synthetic Navigator application.

Request a workbench walkthrough

A separate Claude Code review

In one review, 143 evidence rows were compared with 212 PCI DSS 4.0.1 requirements, producing 50 potential coverage-gap flags.

Those figures describe that review, not workbench performance. Its source evidence is not published here.

IMPLEMENTATION SCOPE

Keep meaning
with the records.

Useful inputs include the source system, status, owner, time, scope, and relevant requirement. Missing or conflicting records should remain visible, with human judgment explicit.

Axiom implements retained memory and weighted context outside a single AI connection. Its completed private migration is described separately; the broader combined architecture is a development direction.

Explore the Axiom research
AXIOM / COMPLETED RECOVERY AND EARLIER ENGINEERING RECORD

Rebuild retrieval.
Keep the source history.

I built and completed a local embedding replacement after losing access to the earlier cloud embedding service. Record identities and source hashes stayed separate from the vectors used to find them, with a switch controlling which retrieval path production would use.

Eligible source identities
31,286
Expected chunks
37,835

The corrected migration manifest defined these counts. They are verified manifest counts, not a claim that the full index had been completed or that retrieval quality had been proved.

Preserve the boundary.

Reconcile eligibility against the existing search rules before expanding what the system can retrieve.

Make the work repeatable.

Freeze the text/chunk recipe and use stable identities and hashes to make restart and correction inspectable.

Separate the acceptance checks.

Retaining records, generating vectors, retrieving the right evidence, and switching production are different tests.

Completed Axiom migration. I subsequently completed re-embedding and tested retained memory and weighting with a fresh Claude instance. The September 18 archive captures an earlier engineering stage. The completed result is my firsthand account; the figures above describe the earlier manifest.

Read the evidence and completion scope
CONTEXT / PEOPLE AND HANDOFFS

The next action depends
on the people around it.

I built source-linked signal ingestion and briefings around messages, meetings, work items, and evidence requests. The implementation carries source identifiers, timestamps, ownership, and unresolved actions forward so a reviewer can distinguish a handoff from unfinished owner work.

The context builder assembles a bounded startup pack from active work, organizational signals, and retained observations, with a manifest of what is included and left out. This is separate from query-time retrieval; either path can carry interpretations that still need verification.

These mechanisms support my work across owners, technical teams and reviewers: carry the source, identify the dependency, and make the next action explicit. Public examples use fictional people and records.

See how I collaborate