The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Project Parva listing page.
Website | API documentation | Quickstart | Public benchmark | Licensing
Project Parva is an open-source Nepali date/time API and conformance project.
It covers BS to AD, AD to BS, Nepali date validation, holidays, working days, Nepal fiscal year logic, BS month metadata, Panchanga computation, proof receipts, local verification, SDKs, MCP tools, and public regression fixtures.
The project exists because Nepali date bugs often hide until a boundary is hit: a frontend calendar table disagrees with backend data, a payroll month has the wrong number of days, a datepicker accepts an invalid BS date, or a future BS date changes after someone already used it in a workflow.
Parva treats those cases as conformance problems, not just conversion problems. It records source and method provenance, separates exact evidence from review-needed evidence, and gives developers a way to test what their Nepali calendar API or Nepali date converter is actually doing.
Three public claims define the project:
2026-08-05 found no second Nepal-focused
API combining BS conversion, location-aware astronomical Panchanga, Nepal
business rules, future-BS research, replay artifacts, and public conformance.72/72 exact month predictions in chronological
rolling validation over the official 2078-2083 BS window, with each target
year trained only on earlier years.Live public evaluation surfaces:
The hosted API is a public evaluation deployment. First requests may be slower when the instance wakes up.
Most Nepali date bugs are small on paper and expensive in context.
Many systems carry hardcoded Bikram Sambat month tables. A backend CSV, a frontend Nepali datepicker bundle, and a reporting job can each have their own copy. They may all look reasonable until one month differs by a day.
That one day can move:
Software agents add another failure mode: if the tool does not expose source, confidence, and boundary data, the model will often answer as if the date is settled. Parva is built to make those boundaries visible.
The project turns public Nepali date failures into fixtures and checks where the evidence is exact enough. When the evidence is partial, it stays marked for review instead of becoming a fake assertion.
If you maintain Nepal-facing payroll, ERP, accounting, attendance, school, cooperative, public-service, government-form, or datepicker software, you can send one small workflow or sample output.
No integration required. No dependency required. No sales call required. No authority claim.
Good inputs:
Checks:
You get:
Request one:
Fast conformance path:
| Area | What it provides |
|---|---|
| Nepali date API | BS to AD, AD to BS, today, validation, month metadata, supported-range metadata |
| Civil proof mode | Replay-verifiable membranes for conversion, validation, holidays, working days, fiscal years, and BS months |
| Panchanga engine | Method-docketed sunrise, tithi, nakshatra, yoga, karana, paksha, vara, ephemeris metadata, and proof receipts |
| Payroll/date-risk audit | CSV/API-oriented decision-support checks for invalid dates, holidays, non-working days, fiscal boundaries, and review-required cases |
| Local verification | Shared proof fixtures and a buildable @project-parva/local-kernel npm package for offline replay checks |
| SDKs | Python and JavaScript clients with proof modes and conservative verification helpers |
| Agent/MCP | Read-only, public-safe agent tool wrappers and MCP adapter surfaces that preserve boundaries and review gates |
| Benchmark | Public Nepali Time Reliability Benchmark for deterministic date reasoning, source awareness, and review behavior |
| Governance | Source/method dockets, public claims checker, route maturity, OpenAPI drift checks, and reproducible public verification |
| Research boundary | Future-BS research kept separate from public authority claims, with compatibility shims only where older imports need them |
Parva tracks public Nepali date issues and turns them into fixtures or runnable checks when the evidence is exact enough. The suite separates verified public issues, reported issues, partial evidence, business workflow evidence, and future-date review cases.
Project Parva's benchmark work contributed a standalone calendar source
consistency guard to yarsa/nepal-compliance.
That check compared duplicated frontend/backend BS month tables. It did not add a Parva dependency, change upstream runtime behavior, or prove production impact.
Run the public issue conformance suite:
Conformance docs:
These fixtures are public regression and review artifacts. They are not calendar publication, legal guidance, tax guidance, payroll approval, banking guidance, or ritual authority.
Base URL:
AD to BS:
BS to AD:
Validate a BS date:
Holiday membership:
Working-day decision support:
Fiscal year:
BS month metadata:
Panchanga summary:
Stable civil routes and Panchanga can return proof receipts:
A proof response includes a membrane capsule, identity hash, witness hash, field provenance, boundary vector, source or method docket references, policy trace, and replay instructions. The verifier must replay operation semantics or validate pinned proof content; hash presence alone is not enough.
Proof-supported civil operations:
convert_bs_to_adad_to_bsvalidate_bs_dateholidayworking_dayfiscal_yearbs_monthsPanchanga proof currently covers method-docketed panchanga_summary with pinned fixture replay and explicit ephemeris metadata.
Parva computes Panchanga signals as method-backed astronomical outputs, not as a final almanac, publication, or ritual decision source.
The proof-carrying Panchanga layer records:
computed_not_official, not_panchanga_authority, and not_ritual_final_authorityJPL support is explicit and bounded. The repo exposes a JPL DE440-family provider interface and kernel-hash disclosure path. Large JPL kernels are not bundled. If no kernel is configured, Parva must not silently claim JPL-backed output.
See docs/PANCHANGA_ENGINE.md, docs/spec/PARVA_EPHEMERIS_PROVIDER_v1.md, and docs/spec/PARVA_PANCHANGA_PROOF_v1.md.
Parva includes a proof-carrying payroll/date-risk workflow for decision support. It checks rows for:
The workflow can emit row-level proof packs and a Timepack-style aggregate report. It is a precheck/audit aid, not legal, tax, payroll, banking, or compliance authority.
Generate shared proof fixtures:
Run backend fixture replay:
Run the local kernel:
The local kernel is a buildable npm package: @project-parva/local-kernel. It verifies shared civil fixtures, Panchanga fixtures, proof packs, and Timepack-shaped artifacts without calling the live API.
Python:
JavaScript:
Packages in this repository are prepared for public-beta dry runs. This README does not claim PyPI publication, npm publication, registry acceptance, external certification, or customer adoption.
Parva is useful for software agents because it gives deterministic temporal tools instead of asking models to guess Nepali dates.
Agent-safe surfaces must preserve:
review_requirednot_authorityPackages:
Parva publishes a deterministic research snapshot for 2084-2200 BS through three read-only endpoints:
The selected pipeline combines sidereal solar-ingress solving, Nepal civil-time assignment, separate broad-reference and official-authority towers, past-only civil-rule learning, source-aware month-start reconciliation, complete-year constraints, prediction sets, and boundary-risk labels. The forecast response includes all twelve month lengths, normalized model support, agreement, boundary distance, risk flags, method versions, and validation scope.
The official 2078-2083 BS window reaches 72/72 exact month matches under chronological rolling validation, with each target year trained only on earlier years. It remains a small development-window result rather than broad independent accuracy proof. Broad validation remains below the project's 528 verified-month evidence threshold. Every forecast carries computed_prediction_not_official, review_required=true, and an authoritative-publication override.
The v7 forecast is now locked by a public source commit, snapshot digest, 117 per-year commitments, and a Merkle root. Later official calendars are scored only from hashed source artifacts reviewed by two people; historical source recovery remains a separate provenance lane.
Current code is split by responsibility:
backend/app lanes such as calendar, panchanga, sources, membranes, rules, timegraph, trust, and servicesbackend/app/research/future_bsbackend/app/future_bs is a compatibility namespace, not the canonical implementation locationtests/backend_runtimetests/local_kerneldata/source_archive/moha with data/source_archive/moha/manifest.jsonCore architecture files:
Run:
Focused checks:
Frontend:
Safe claims when the relevant verification commands pass:
Do not claim:
The public reproducibility gate is the source of truth for release readiness:
The civil temporal core has replay-verifiable proof support and local fixtures. Panchanga has a proof-carrying method-docketed path with fixture replay and a bounded JPL provider interface. Future-BS publishes a curated research snapshot while raw model workflows remain controlled.
The external ceiling is not complete. There are no real external witnesses, institutional signatures, official approval, third-party certification, or customer/adoption proof in this repository.
Project Parva is licensed under AGPL-3.0-or-later. Network deployments must
set PARVA_SOURCE_URL to the corresponding source repository or source archive
for the deployed version. The application exposes /source as a redirect to
that configured location and adds a rel="source" link to HTTP responses.
Commercial embedding licenses are also available for proprietary products at NPR 100,000-300,000 per vendor per year, based on named product scope. See docs/COMMERCIAL_LICENSING.md.
Deployment details are documented in docs/DEPLOYMENT.md.
Near-term:
Contributions should preserve Parva's core rules:
Before opening a pull request, run:
Use Python 3.11 and Node 20 for reproducible verification.