AKTRU Verified AI Identity Builder

A local-first, human-reviewed tool that turns inconsistent website and supplied registry evidence into traceable machine-readable company identity proposals.

Comment

Inspiration

Companies are often represented differently across their websites, metadata, Schema.org markup, machine-readable files, local domains, and registry documents. These inconsistencies make it harder for people, search engines, and AI systems to understand which entity is being described and which source supports each claim.

I wanted to build a tool that would not simply merge all available information into one answer. Instead, it should preserve provenance, expose uncertainty, and keep the final decision with a human reviewer.

That idea became AKTRU Verified AI Identity Builder.

What it does

AKTRU Verified AI Identity Builder is a local-first web application that audits how a company is represented across:

  • website content;
  • metadata;
  • structured data such as Schema.org and JSON-LD;
  • machine-readable identity files;
  • an optional registry document supplied by the user.

The tool classifies detected values into four evidence classes:

  1. Supported by supplied registry document The value is present in a registry document supplied by the user.

  2. Declared by website owner The value is explicitly published in website-controlled content.

  3. Inferred from technical content The value is derived from metadata, URLs, structured data, or technical relationships.

  4. Unresolved The supplied evidence is insufficient for a safer classification.

Technical consistency is kept separate from registry evidence coverage. Before any value is included in an exported proposal, the user must explicitly approve it.

The application can export:

  • technical audit reports;
  • Markdown and JSON summaries;
  • a before-and-after manifest;
  • deterministic machine-readable identity proposals;
  • a ZIP evidence package.

The tool does not modify the original files.

Privacy and trust boundaries

All selected files are processed locally in the browser.

The application has:

  • no backend;
  • no database;
  • no user accounts;
  • no telemetry;
  • no external analysis API.

A supplied registry document is treated only as evidence provided by the user. The tool does not independently verify its origin, authenticity, or current validity.

A SHA-256 hash identifies the exact bytes analyzed, but it is not presented as proof of authenticity.

The tool does not certify a company, replace official registries, verify domain ownership, or guarantee indexing, visibility, or ranking.

How I built it

The project was built with OpenAI Codex during OpenAI Build Week 2026.

The application uses:

  • React;
  • TypeScript;
  • Vite;
  • browser File APIs;
  • GitHub Actions;
  • GitHub Pages.

Codex helped with:

  • repository architecture;
  • implementation of the auditing engine;
  • local file parsing;
  • deterministic export generation;
  • TypeScript refactoring;
  • automated testing;
  • accessibility improvements;
  • responsive design;
  • GitHub Pages deployment;
  • pull requests, merges, tags, and releases;
  • technical documentation.

I defined the product goals, evidence boundaries, terminology, privacy constraints, acceptance criteria, and final publication decisions.

The review-and-repair loop

One of the most important parts of the project was not the first implementation, but the validation process that followed.

I asked several AI systems to independently interpret the public application. Their responses revealed where the product description was clear and where models still overreached.

For example, the first release worked correctly in a browser, but a plain HTML fetch exposed almost no meaningful content because the interface was rendered entirely by React.

That meant some crawlers and AI agents could see only a minimal application shell.

The issue was converted into a bounded engineering task for Codex. Codex then:

  • added meaningful static HTML content;
  • added regression tests for crawlability;
  • improved evidence terminology;
  • clarified registry-document limitations;
  • anonymized all public demonstrations;
  • added llms.txt and llms-full.txt;
  • documented the audit methodology;
  • published version v1.0.1.

The raw public HTML increased from a minimal shell to more than 6,000 bytes of meaningful explanatory content available without JavaScript.

This created a practical loop:

AI interpretation → human correction → scoped Codex task → automated tests → release → multi-model revalidation

Challenges

Preserving evidence provenance

The main conceptual challenge was preventing values from different sources from being silently merged.

A value found in a supplied registry document should not automatically validate every similar claim on a website. The system therefore keeps source context and evidence classification attached to each value.

Avoiding false verification claims

Early terminology such as “verified from registry” could imply that the application authenticated the document itself.

The terminology was changed to:

Supported by supplied registry document

This more accurately reflects what the tool can prove.

Client-side processing

The application had to inspect multiple local files, parse HTML and JSON, detect encoding issues such as BOM, generate reports, and prepare ZIP exports without uploading anything.

Deterministic exports

The same approved inputs should produce stable outputs. This required normalizing values, ordering exported fields consistently, and separating approved values from unresolved or conflicting ones.

Crawlability

The interactive application requires JavaScript, but the product description, methodology, evidence classes, and limitations must still be visible to plain HTTP clients and AI crawlers.

Human control

The system had to remain useful without automatically turning detected values into published claims. Human approval is therefore required before export.

Accomplishments that I am proud of

The project evolved from a functional prototype into a public, documented, and testable release.

Key accomplishments include:

  • a complete local-first workflow with no backend;
  • separate Technical Consistency and Registry Evidence Coverage scores;
  • explicit human approval before export;
  • deterministic generation of seven proposed machine-readable files;
  • public synthetic demonstrations in Polish, English, and German;
  • meaningful static HTML available without JavaScript;
  • public llms.txt and llms-full.txt files;
  • automated regression tests for crawlability and evidence terminology;
  • deployment through GitHub Actions and GitHub Pages;
  • a documented public release, v1.0.1.

What I learned

I learned that traceability is not the same as truth.

A system can show exactly where a value came from while still being unable to prove that the source itself is authentic or current.

I also learned that multiple AI systems repeating the same conclusion do not automatically create multiple independent proofs. Models may share assumptions, summarize too aggressively, or work from incomplete inputs.

The most valuable use of multiple models was not agreement. It was disagreement that could be turned into tests and product improvements.

I also saw how effective Codex can be when the goal, constraints, and proof of completion are clearly defined. The strongest results came from giving Codex bounded tasks with explicit regression checks rather than broad requests to “improve the project.”

Current validation

Version v1.0.1 passed:

  • TypeScript type checking;
  • 30 of 30 automated tests;
  • production build;
  • dependency audit with 0 known vulnerabilities;
  • mobile validation at 375 px;
  • keyboard accessibility checks;
  • console validation without errors or warnings;
  • direct-path and refresh fallback checks;
  • public asset checks;
  • public llms.txt and llms-full.txt checks;
  • static HTML validation without JavaScript.

The public demonstrations use synthetic or anonymized data:

  • Hospitality Demo PL;
  • Hospitality Demo EN;
  • Furniture Demo DE.

What is next

The next step is to use the tool as the foundation for a professional human-reviewed service:

  1. audit a company’s website and supplied evidence;
  2. identify conflicts and missing identity signals;
  3. review the findings with the client;
  4. prepare corrected structured data and machine-readable files;
  5. obtain human authorization;
  6. publish the approved changes;
  7. test how different AI systems interpret the resulting public identity node.

The goal is not automatic certification.

The goal is to create a safer, more transparent, and more reproducible way to prepare company identity signals for AI and search systems.

Links

Built With

Share this project:

Updates