Checksum / EvidenceOS

Checksum is an evidence operating system for turning real work into trustworthy, human-reviewable context. It helps people and organizations collect evidence, guide the next work process, and make better decisions without pretending that activity volume or AI output can replace judgment.

Checksum is designed as one system with role-aware experiences. A school, an employer, a student, a developer, a cloud engineer, a DevOps practitioner, a supervisor, or another participant may see different workflows, fields, permissions, and review queues, but they operate on the same evidence model and the same auditable foundation.

Product direction

The first product surface is an evidence-first engineering review workspace. It helps a reviewer move from a claim to a considered next question by keeping four things distinct:

• What a person says about their work.
• What connected sources and supplied artifacts show.
• What the Checksum agent infers or drafts.
• What a human reviewer confirms or decides.

The system is intentionally not an automated hiring judge, an academic misconduct detector, a student surveillance tool, or a replacement for an LMS or a resume. Its job is to make the evidence and uncertainty easier to understand.

One system, many workflows

School and employer use cases are features and workflow configurations inside the EvidenceOS Checksum system. They are not separate products or conflicting data silos. The shared engine supports:

• Employer and founder review of engineering candidates and project claims.
• Student project evidence, group contribution context, continuous assessment, and supervision.
• Supervisor check-ins, action items, milestone records, and review briefings.
• Developer, cloud engineer, DevOps, platform, data, and other technical-role workflows.
• Future faculty-specific evidence adapters for business, law, sciences, design, medicine, education, and more.

Each experience can define its own workflow steps, evidence sources, visibility rules, language, escalation path, and reviewer responsibilities while retaining a stable canonical record.

Event-aware KYC and onboarding

Checksum begins role-aware context capture during account creation. A new account selects Builder or Founder, completes the corresponding lightweight KYC context flow, and is then routed into the right onboarding journey.

The purpose is not only identity verification. It is context verification and workflow routing. Depending on the account and consented context, the system may understand that a person is participating as:

• A university, department, lecturer, supervisor, teaching assistant, or student.
• An employer, founder, recruiter, hiring manager, candidate, or reviewer.
• A developer, cloud engineer, DevOps engineer, platform engineer, data practitioner, or another technical role.
• A mentor, project collaborator, evaluator, or organization administrator.

KYC data will be collected only when needed, with explicit purpose, appropriate consent, role-based access, auditability, and institution or organization retention rules. The resulting role and account context determine which work processes, evidence requests, permissions, agent prompts, and workspace actions are appropriate.

The intended experience is: event creation or invitation -> context and KYC -> role and permissions -> personalized workflow -> evidence collection -> human review.

Evidence model

The long-term canonical model is stable and versioned. It can include:

• Workspace: organization, school, employer, or project context.
• Member: identity, role, permissions, consent, and event participation.
• Project: work being reviewed, its context, owners, and milestones.
• Claim: a person statement about ownership, skills, decisions, or outcomes.
• Evidence: repository activity, pull requests, reviews, tests, deployments, uploads, drafts, reflections, meeting records, or linked sources.
• Workflow: a versioned process definition and its required steps.
• Workflow run: the current state of a person or team process across web and future channels.
• Review brief: evidence, interpretation, uncertainty, and questions prepared for a human.
• Approval and audit record: what was confirmed, by whom, and when.

Git activity is a signal, not definitive authorship proof. A person may contribute through architecture, research, testing, reviewing, coordination, deployment, or other work that is not represented by commit count. Inactivity is never treated as proof of dishonesty.

AI agent and declarative workflows

The Checksum agent guides users through the next useful step. It may ask about ownership and trade-offs, request missing proof, summarize a project, prepare a supervision briefing, draft an evidence record, or remind a participant about an agreed action.

The web application is the first channel. Future channels, including WhatsApp, may support short reflections, reminders, and guided questions using the same workflow state. The channel is not the workflow. Private messages never become public or official claims without clear user approval.

YAML or TOML defines workflow behavior, not an arbitrary production database. A workflow definition may describe steps, prompts, channels, requirements, routing, visibility, and mappings into the canonical schema. Every agent write must pass validation, permission checks, provenance capture, and human approval when it affects an important claim.

Example flow:

workflow definition
    -> next question or task
    -> validated evidence draft
    -> user or reviewer approval
    -> canonical record and audit trail

Current prototype

The current Next.js prototype includes:

• A public landing page explaining the evidence-first proposition.
• Sign up, sign in, password reset, and verification-code screens.
• A Builder workspace under /builder with overview, projects, applications, onboarding, project detail, and settings routes.
• A Founder workspace under /founder with overview, candidates, job postings, onboarding, and settings routes.
• Role-aware account creation with Builder/Founder routing into /builder/kyc or /founder/kyc.
• A floating shadcn Aria sidebar for each private workspace.
• A React Aria command menu and review drawer.
• Hugeicons for interface icons, with no Lucide, Radix UI, or Base UI dependency.
• Keyboard theme switching by pressing d outside form fields.
• A README and architecture source files under docs/.

The prototype is intentionally front-end focused. It demonstrates the product language, navigation, workflow concepts, and review model. Authentication, KYC, source integrations, storage, notifications, and production agent orchestration are future implementation work.

Technology and conventions

• Next.js 16 with the App Router.
• React 19 and TypeScript.
• Bun for package management and scripts.
• shadcn aria-sera generated conventions.
• React Aria Components for accessible interactive behavior.
• Hugeicons as the project icon system.
• app/globals.css as the home for custom design tokens and styles.
• components.json as the source of truth for component configuration and aliases.

Run locally

bun install
bun dev

Open http://localhost:3000. Available prototype routes include /, /sign-up, /sign-in, /forgot-password, /verify, /builder, /builder/kyc, /builder/applications, /builder/projects, /builder/onboarding, /builder/settings, /founder, /founder/kyc, /founder/candidates, /founder/onboarding, and /founder/settings.

Architecture files

• High-level architecture
• Detailed solution architecture

Guardrails

Checksum must preserve human agency, explainability, privacy, and proportionality. It must not produce an opaque ranking as a substitute for review, make automatic hiring or grading decisions, accuse a student of misconduct from a discrepancy, expose private evidence to the wrong role, or treat an AI draft as a confirmed fact.

The system should make the next responsible action clearer while keeping the final decision with the person or institution accountable for it.