Skip to main content
Parmana is an Execution Trust Infrastructure platform. The project prioritizes correctness, determinism, immutability, and verifiable execution over implementation convenience.

​
Architecture first

Every significant architectural change should begin with documentation. Use this decision process:
  1. Is this a bug fix? Implement the fix with tests.
  2. Is this a new feature? Create an RFC describing the proposal.
  3. Does the feature change architectural behavior? Create or update an Architecture Decision Record (ADR).
  4. Does the change modify a normative platform contract? Update the relevant specification in docs/.

​
Core principles

Deterministic execution

Identical inputs must always produce identical decisions.

Immutable domain model

No trust-chain artifact supports an update operation.

Independent verification

Verifying a record shouldn’t require trusting the runtime that produced it.

Append-only evidence

Corrections are new artifacts, never edits to history.

Cryptographic agility

Algorithms are swappable implementation details, not fixed domain concepts.

Separation of concerns

Each package under packages/ has one responsibility.
Changes that violate these principles require an approved ADR.
This documentation surfaces several places where the current implementation doesn’t yet fully live up to these principles — see REST API → Authentication, REST API → Error Model, Packages → replay, and Packages → verification for concrete examples. Contributions that close those gaps are exactly the kind this project wants; contributions that quietly paper over them without an ADR are not.

​
Testing requirements

All changes should include appropriate automated tests:
  • Unit tests for new domain behavior.
  • Regression tests for bug fixes.
  • Conformance tests when platform contracts are affected.
The build should pass: 
npm run build
npm run typecheck
npm test

​
Coding standards

  • Use TypeScript strict mode.
  • Prefer immutable objects.
  • Avoid hidden side effects.
  • Keep classes focused on a single responsibility.
  • Document public APIs.

​
Pull requests

Pull requests should include:
  • A clear description.
  • A linked issue or RFC, if applicable.
  • Updated documentation when required.
  • Passing build and test results.

​
Where documentation lives

ContentLocation
Normative specificationsdocs/
Architecture decisionsdocs/adr/
Future proposalsdocs/rfcs/
Implementation guidesdocs/guides/

​
Philosophy

Parmana is designed to establish trust between authority and execution. Every contribution should strengthen that goal.

Architecture Overview

The principles above, in context.

Security Model

The guarantees these principles support.