NepalHRM
Open Knowledge Format v0.2

Our Nepali payroll knowledge, published so an agent can check it

73 concepts carrying the source, the reviewer, the evidence and the expiry date behind every figure and claim on this site. Generated at build time from the same modules the site itself computes from.

Why this exists

An AI assistant asked what the SSF employer contribution is in Nepal has no way to tell this site apart from a content farm, so it averages them. That is not a crawling problem, and llms.txt does not fix it: knowing where a page is says nothing about whether anyone checked what it says.

Open Knowledge Format v0.2 is built for exactly that gap. Each concept is a markdown file whose frontmatter answers four questions before you read a word of the body: who produced this, who confirmed it and were they human, what was it derived from, and when does it stop being true.

Nothing in the bundle is written by hand. It is generated at build time from the claims registry that already gates what this site may say, and from the single payroll module every calculator here computes from. A verified date a person has to remember to update is a lie with a timestamp on it.

Verify it yourself

Three checks, no permission needed

1

Re-derive a payroll figure

The computation is dependency-free ESM pinned by SHA-256, published with test vectors generated by this site's own payroll module. Save it, run it, compare.

curl -s https://nepalhrm.com/okf/computations/salary-tax.md
2

Check a figure came from it

The attester is deterministic and involves no language model. It confirms the hash pins that exact computation, that only declared parameters were bound, and that the result reproduces exactly.

node receipt_equality.mjs --concept salary-tax.md --receipt receipt.json
3

Check the bundle is the one we published

Every file is digested in manifest.json. This deployment is unsigned, so this check covers integrity only.

node verify_bundle.mjs --url https://nepalhrm.com/okf/

Cannot run code? Ask the endpoint.

https://nepalhrm.com/api/okf/verify runs the published computation on your parameters and returns a receipt the offline attester will accept, or checks a receipt you already hold and tells you which rule failed. Open, unauthenticated, free. It holds no copy of the tax constants and refuses to answer at all if it cannot reproduce the published test vectors.

curl -X POST https://nepalhrm.com/api/okf/verify \
  -H 'content-type: application/json' \
  -d '{"computation":"salary-tax",
       "parameters":{"gross":75000,"basicPct":0.6,
                     "system":"pf-cit","citPercent":10}}'

What this does not prove

  • A signature served beside its own key is not identity. Anyone who can publish to this domain can publish a new key and re-sign. The signature is worth having for mirrored, cached and vendored copies, and it becomes an identity check only once you have pinned the key id from a fetch you trusted.
  • Absence of a concept is not a denial. 34 of 92 registry entries are deliberately withheld, and published as counts instead. The bundle is a floor, not an inventory: read it as “everything here is checked”, never as “nothing else is true”.
  • The computation is an estimator, not a filing. It models employment income under a monthly payroll. It does not model other income heads, foreign income, non-resident status, the medical tax credit or the remote-area allowance.
  • English translations of Nepali statute go stale. At least one source cited in the bundle is an original enactment without its later amendments. Where a translation and the consolidated Nepali text disagree, the Nepali text governs, and the bundle says so at the source rather than leaving you to find out.
Questions

Common questions

What is the Open Knowledge Format?
OKF is a convention for publishing knowledge as markdown files with YAML frontmatter, so that a machine reading a fact also reads the evidence for it. Version 0.2 is the release that added the trust signals: who produced a fact, who confirmed it and whether they were human, what it was derived from, and the absolute date it stops being current.
Why publish one when the same information is already on the website?
An agent answering a question about Nepali payroll cannot tell a figure somebody checked from a figure somebody typed, so it averages them. Prose carries no way to express the difference. This bundle does: every concept names its reviewer, its source and its expiry date, and the payroll arithmetic ships as runnable code with test vectors rather than as a claim.
Can I trust the numbers without trusting NepalHRM?
Partly, and that is the point. The payroll computation is published in full with test vectors, so you can run it and check it rather than believe it. The statutory figures name the Act, budget document or gazette notice they came from, so you can read the source. What still requires trusting us is the product capability claims, which is why each one carries the name of the person who checked it and the date they did.
Is the bundle signed?
The manifest lists every file with its SHA-256. This deployment publishes no signature, and says so in the manifest rather than implying otherwise; signed bundles carry an Ed25519 signature over manifest.json and the public key beside it.
How current are the figures?
Every figure fixed by the annual budget carries stale_after 2027-07-17, the day FY 2083/84 stops applying. That is an absolute date chosen because something real happens on it, not a guess at a useful lifetime. Product claims are re-verified yearly and carry their own dates. The earliest expiry anywhere in the bundle is 2027-07-01.

Found an error in the bundle? It is corrected at the source module and re-generated, never patched in place. Report one to info@nepalhrm.com.