Evidence before inference.

Problem

People often keep role aspirations, skill estimates, and project proof in disconnected documents. The result is not merely missing data; it is unclear reasoning. A polished profile can hide which target was chosen, what evidence supports a claim, and why a next step was suggested.

Credhalo makes those links explicit. It is not an actual AI recruiting service, does not rank candidate quality, does not promise employment, and does not connect to recruitment databases.

Principles

• Local by default: work is stored in the current browser.
• Evidence over assertion: skill claims can link to concrete project work.
• Rules over mystique: every status and recommendation has a readable condition.
• Consent at boundaries: download, wallet connection, and proof anchoring remain separate actions.
• Honest states: Local Demo is not on-chain; pending is not confirmed.

Local architecture

The interface is a client-side workspace served as a web application. Role, skill, evidence, receipt, wallet display, and proof-history records use versioned localStorage keys. Gap computation executes in the browser. Receipt digests use the browser Web Crypto implementation of SHA-256. There is no product database, account system, cloud synchronization, or background upload in this MVP.

Browser storage is convenient, not archival. Clearing site data, private browsing behavior, storage quotas, or device loss may remove records. Users should explicitly download important receipts.

Skill and evidence model

A target role contains a title, direction, priority, and 5–8 skills. Each skill has a current level (1–5), target level (1–5), confidence (low, medium, high), core/supporting priority, and notes.

An evidence entry links exactly one skill to a project name, http(s) URL, completion date, evidence type, and description of at least 12 characters. Validation establishes field completeness only; it does not verify the truth, ownership, quality, accessibility, or continued availability of a linked resource.

Gap rules

The three labels are deterministic. Needs practice means current level is below target. Needs evidence means the target is met but no complete linked evidence passes field validation. Covered means the target is met and at least one complete evidence entry exists.

The displayed coverage score is the average of min(current level ÷ target level, 1) × confidence weight, where high = 1.0, medium = 0.85, and low = 0.7. Evidence completeness is complete evidence entries divided by skill count, capped at 100%. Up to three recommendations are sorted by status severity and then lowest score. These recommendations are transparent local rules, not model reasoning.

Snapshot and receipt schema

A snapshot freezes the current role, normalized skill fields, evidence summaries, full rule result, ISO timestamp, and schema version. Canonical JSON is formed by recursively sorting object keys. SHA-256 is computed over the schema name, version, timestamp, and snapshot. The receipt stores algorithm and lowercase hexadecimal digest, a verified generation status, and proof state.

The digest can reveal whether the same canonical snapshot bytes were later changed; it does not certify authorship, truth, skill level, identity, or professional standing. Copy and JSON download occur only after explicit user actions.

Wallet boundary

Wallet connection requests only the user-selected public address and active chain ID. Connection itself never signs, submits a transaction, requests token approval, makes a payment, or anchors a receipt.

The connected public identity is used only to populate the explicit proof preview. The interface does not invent a wallet when no provider is present.

Proof lifecycle

Optional BOT Chain proof is separate from identity connection. The user selects a Growth Receipt and reviews its business proof ID, digest, wallet, contract, chain, zero value, and anchorGrowthReceipt(bytes32) operation before a second confirmation. Without a configured contract and call selector it is labeled Local Demo / Unavailable. Local records never include invented transaction or block data.

For configured submission, the interface records the provider transaction hash as pending, then queries the provider receipt and block timestamp. It distinguishes pending, confirmed, rejected, and failed results and provides manual recovery. Explorer links are shown only for real transaction hashes.

Threat model

• Malicious or inaccessible links: URLs are not fetched or endorsed by Credhalo; users should inspect destinations.
• Local tampering: browser records can be edited by anyone with device access. Digests expose later changes only when an original receipt is available for comparison.
• Wallet phishing: the connection function is limited to account and chain queries; transaction methods exist only in the visibly separate proof console.
• Device and extension risk: browser extensions, compromised devices, and wallet software remain outside Credhalo’s control.
• Metadata leakage: publishing a receipt may expose role, project descriptions, and URLs chosen by the user.

Limitations

Credhalo does not validate project authorship, perform background checks, issue certificates, scrape jobs, match people to employers, offer career or legal advice, support teams, or guarantee persistence. The level scale is self-reported. The map should support reflection, not replace human judgment.

Roadmap

Possible work includes receipt verification tools, encrypted export, accessibility improvements, configurable rule profiles, and opt-in proof adapters. Roadmap items are exploratory, may change, and are not commitments.

Disclaimers

The product is provided for informational and self-reflection purposes. It is not a hiring decision system, employment service, credentialing authority, financial product, or guarantee of any outcome. Users remain responsible for their claims, links, wallet actions, backups, and legal obligations.