BenchmarksStack Ranking
APIsPricingStandardDocsWhite PaperTokenBlogAboutSecurity Demo
Log InTalk to UsGet API Key
Open Standard

HICI — H33 Independent Code Index

The open-source zero-knowledge scoring standard for software procurement. STARK-attested. Dilithium-signed. Nobody sees the code. Everyone sees the grade.

Get a HICI Assessment View on GitHub Read the Formula →
6
Evaluation Dimensions
0-100
Score Range
3-Key
Signature Families
0
Lines of Code Exposed
Overview

What is HICI?

HICI is a publicly available scoring methodology for evaluating software quality, security, and compliance — without exposing the source code. The evaluation runs locally on the vendor's machine. Only the cryptographic proof and the grade leave the building.

HICI produces a single 0–100 score across 6 dimensions, sealed by a STARK zero-knowledge proof and signed with H33-3-Key (Ed25519 + Dilithium + FALCON). Any third party can verify the grade without seeing the code, without trusting the vendor, and without trusting H33.

The Formula

Open Source. Deterministic. Verifiable.

The HICI scoring formula is public. There are no hidden weights, no subjective adjustments, no proprietary modifiers. What you see is what the circuit computes.

HICI = Σ(wᵢ × Dᵢ) for i ∈ {1..6} Where: D₁ = Code Quality w₁ = 0.20 D₂ = Security Posture w₂ = 0.25 ← heaviest weight D₃ = Architecture w₃ = 0.15 D₄ = Performance w₄ = 0.15 D₅ = Compliance w₅ = 0.15 D₆ = Maintenance Risk w₆ = 0.10 HICI_score = w₁D₁ + w₂D₂ + w₃D₃ + w₄D₄ + w₅D₅ + w₆D₆ Security Posture (D₂) carries the highest weight (0.25). If D₂ < 70, the overall grade is capped at C+ regardless of other scores. If D₂ < 50, the certificate is automatically Failed.
Grade Scale

From A+ to F

Every HICI score maps to a letter grade. The grade is what appears on the public certificate. The score is what appears in the detailed proof.

Score Grade Meaning
95–100 A+ Exceptional — production-ready, security-hardened, fully compliant
90–94 A Excellent — minor improvements possible
85–89 A- Strong — meets all critical thresholds
80–84 B+ Good — ready for production with noted items
75–79 B Acceptable — some areas need attention
70–74 B- Adequate — meets minimums
65–69 C+ Below average — security or maintenance concerns
60–64 C Marginal — significant gaps
55–59 C- Poor — major remediation needed
50–54 D Failing — critical security or quality issues
0–49 F Failed — does not meet minimum standard
Evaluation Dimensions

6 Dimensions. Weighted. Non-Negotiable.

Each dimension is scored independently by the evaluation circuit. The weights are fixed in the open-source formula. Security Posture carries a hard cap — no amount of code quality can compensate for poor security.

D1
w = 0.20

Code Quality

Structural health of the codebase. How readable, tested, and well-maintained is the code?

  • Cyclomatic complexity
  • Test coverage
  • Documentation coverage
  • Linting conformance
  • Dead code ratio
  • Dependency freshness
D2 — Highest Weight
w = 0.25

Security Posture

The heaviest weight because security failures cascade. If this dimension scores below 70, the overall grade is capped at C+. Below 50 is an automatic fail.

  • Known vulnerability count (CVE)
  • Secret exposure detection
  • Authentication strength
  • Encryption algorithm currency (PQ-readiness)
  • Input validation coverage
  • Dependency supply chain risk
D3
w = 0.15

Architecture

Structural soundness. Well-architected code survives team changes, scaling pressure, and feature velocity.

  • Separation of concerns
  • API surface consistency
  • Error handling patterns
  • Logging hygiene
  • Configuration management
  • Circular dependency count
D4
w = 0.15

Performance

Runtime behavior patterns detected through static analysis. Algorithmic red flags that manifest under load.

  • Algorithmic complexity hotspots
  • N+1 query patterns
  • Memory allocation patterns
  • Concurrency safety
  • Response time characteristics
D5
w = 0.15

Compliance

Regulatory and license alignment. Does the code handle data correctly, use compatible licenses, and leave an audit trail?

  • License compatibility
  • Data handling patterns (PII detection)
  • Regulatory framework alignment (SOC 2, HIPAA, GDPR markers)
  • Audit trail completeness
D6
w = 0.10

Maintenance Risk

Long-term sustainability. Will this codebase still be maintainable in 2 years if the original team leaves?

  • Bus factor (contributor concentration)
  • Dependency age and abandonment risk
  • Breaking change frequency
  • Migration debt
  • Test brittleness
Cryptographic Attestation

Every Grade Is Sealed

A HICI score is not a PDF. It is a cryptographic artifact. Three independent verification layers ensure nobody — not the vendor, not H33, not a malicious intermediary — can alter the grade after evaluation.

Layer 1

Merkle Root

Commits to the exact codebase state at evaluation time. Every file, every line. Change one character after the fact and the root changes, invalidating the proof entirely.

Layer 2

STARK Proof

Proves the evaluation circuit ran correctly on the committed codebase. No shortcuts, no faked scores. SHA3-256 hash function. No trusted setup required. Transparent and post-quantum secure.

Layer 3

H33-3-Key Signature

Ed25519 + Dilithium + FALCON nested temporal binding. Three independent mathematical families. Post-quantum. All three must be forged simultaneously to tamper with the grade.

Process

Three Steps. Zero Code Exposure.

The vendor runs the evaluation. H33 hosts the proof. The buyer verifies the math. At no point does anyone besides the vendor see the source code.

01

Run Locally

Vendor runs the open-source HICI CLI on their machine. The evaluation circuit analyzes the codebase across all 6 dimensions. Code never leaves the vendor's environment.

02

Seal & Submit

CLI produces a Merkle root, STARK proof, and signed grade. Only the proof and grade are sent to H33 for hosting. Never the code. Never the file contents. Never the repository.

03

Verify Independently

Buyer clicks the proof link. Sees the grade card. Verifies the STARK proof and all three signatures independently using the open-source verification tool. Trust the math, not the vendor.

Comparison

HICI vs Traditional Code Review

Traditional code review requires full source access, human subjectivity, and weeks of elapsed time. HICI replaces trust with proof.

Traditional Review HICI
Code visibility Reviewer sees all source code Nobody sees the code
Trust model Trust the reviewer Trust the math
Reproducibility Subjective, varies by reviewer Deterministic, STARK-proven
Post-quantum N/A SHA3-256 STARK + Dilithium
Tamper evidence Report can be edited Merkle root invalidates on any change
Speed Days to weeks Minutes
Cost $10K–$100K per review $330 (Procure-2 at Enterprise+ rate)
Open Source

The Formula Is Public. The Proof Is Mathematical.

HICI is not a proprietary black box. The formula, evaluation circuits, and CLI are all open source. Anyone can audit, fork, or build on top of HICI.

Open Source Components

Complementary Standards

Relationship to HATS

HATS and HICI are complementary standards. They evaluate different things and can be used independently or together.

HATS + HICI = Full Coverage

HATS certifies AI system operational controls. HICI evaluates codebases. Together, they answer both the operational and the code-level question.

HATS

“Are the system's security controls operating as required?”

HICI

“Is the code itself well-built, secure, and maintainable?”

Frequently Asked Questions

FAQ

Common questions about the HICI standard, evaluation process, and cryptographic guarantees.

Is HICI open source?

Yes. The formula, evaluation circuits, and CLI are Apache 2.0. Anyone can audit the scoring methodology, run evaluations locally, and verify grades independently.

Does H33 see my source code?

No. The HICI CLI runs locally on your machine. Only the Merkle root, STARK proof, and signed grade leave your environment. H33 hosts the proof page but never sees a single line of code.

How is HICI different from SonarQube or CodeClimate?

SonarQube and CodeClimate require code access and produce unattested reports. HICI evaluates code without seeing it, produces a STARK-attested score, and signs it with post-quantum signatures. The grade is cryptographically verifiable by any third party.

Can a vendor fake a HICI score?

No. The Merkle root commits to the exact repository state. The STARK proof verifies the evaluation circuit ran correctly on that exact state. Changing the code, the evaluation logic, or the score invalidates the proof. Three independent signature families (Ed25519, Dilithium, FALCON) must all be forged simultaneously.

What does the Security Posture cap mean?

If a codebase scores below 70 on Security Posture (D₂), the overall HICI grade is capped at C+ regardless of how well other dimensions score. Below 50, the certificate automatically fails. Security is non-negotiable.

Get Started

Evaluate Your Codebase

Zero-knowledge. STARK-attested. Post-quantum signed. Get a HICI grade for any codebase in minutes — without exposing a single line of code.

Get a HICI Assessment → Read the Formula View on GitHub