---
type: Policy
title: How NepalHRM verifies what it publishes
description: The process behind the trust signals in this bundle, and an explicit account of what is withheld from it.
resource: https://nepalhrm.com/okf/
tags: [nepalhrm, policy, trust]
generated:
  by: process:nepalhrm-site-build
  at: 2026-08-07T00:00:00Z
verified:
  - by: human:rajesh
    at: 2026-08-07T00:00:00Z
status: stable
sources:
  - id: nepalhrm-payroll-module
    resource: nepalhrm:lib/nepal-payroll.ts
    title: The single module every NepalHRM calculator, payslip and tool on this site computes from
    author: process:nepalhrm-site-build
---

# How NepalHRM verifies what it publishes

## Product capabilities

This website holds no product code. Every capability it claims is an assertion about a different system, so each one is recorded in a build-gated registry carrying an owner, the date a person last checked it against the running application, and a written record of what they read. A marketing page that makes a claim with no registry entry **fails the build**. That gate is why the `verified` dates in this bundle mean something: they are not attestations typed into a document, they are the mechanism that lets the copy ship at all.

| Registry status | Entries | Published here |
|---|---|---|
| shipped-prod | 58 | yes, 58 concepts under [product/](../product/index.md) |
| unverified | 20 | no |
| planned | 11 | no |
| staging-only | 3 | no |

Only `shipped-prod` entries become concepts. The others are reported above as counts and withheld as documents, for two different reasons: publishing `planned` would put a roadmap in a machine-readable file, and publishing `unverified` would tag live copy as doubtful in a format built for agents to act on that signal. Both are real states, so both are counted rather than hidden.

**Absence of a concept is not a denial.** This bundle is a floor, not an inventory: read it as "everything here is checked", never as "nothing else is true".

## Evidence

Each product concept carries one source describing the KIND of check performed, not the literal evidence string. The registry's own evidence records internal repositories and file paths; those are withheld, and what is published instead is whether the application source was read directly, the running application was exercised, or only the registry was consulted. The distinction is the part a consumer can act on.

## Statutory figures

Nepali tax, contribution and wage figures are not copied into prose anywhere on this site. They are generated from one module, which is what the calculators, the payslip generator and this bundle all compute from. A figure therefore cannot be correct in one place and stale in another; it is correct everywhere or wrong everywhere, and the second case is a build failure.

Three rules govern how they are sourced:

* **The consolidated Nepali text governs.** English translations of Nepali statute are frequently the original enactment without later amendments, and at least one source cited in this bundle is exactly that. Where a translation and the consolidated Nepali text disagree, the Nepali text is authoritative.
* **Absolute dates, never relative ones.** Every figure fixed by the annual budget carries `stale_after: 2027-07-17`, the day FY 2083/84 ends. Figures set by notice instead carry the review date of the notice list.
* **Attested where it is computed.** A figure that is the output of arithmetic is published as an [Attested Computation](../computations/index.md) with a runnable implementation and test vectors, so it can be re-derived rather than trusted.

## Corrections

Errors in this bundle are corrected at the source module and re-generated, not patched in place. Report one to [info@nepalhrm.com](mailto:info@nepalhrm.com).