Skip to main content
typescript/src/models/index.ts re-exports one interface file per domain concept. These mirror the canonical domain model in @parmana/shared/src/domain/ closely — they’re independently hand-written types in the SDK package, not generated from @parmana/shared, but field-for-field they match for every type checked below.
ModelFileConcept
Authorityauthority.tsAuthority
Authorizationauthorization.tsAuthorization
Intentintent.tsIntent
BusinessTransaction, BusinessTransactionMetadatabusiness-transaction.tsBusiness Transaction
Execution, Decisionexecution.tsExecution, Decision
Overrideoverride.tsOverride
PolicyReferencepolicy.tsPolicy
Receiptreceipt.tsReceipt
ReplayResultreplay-result.tsReplay
ExecutionTrustRecordtrust-record.tsExecution Trust Record
Verificationverification.tsVerification
Decision is defined inside execution.ts alongside Execution, not in its own file — there’s no separate decision.ts model despite Decision being documented as its own concept.

​
PolicyReference vs. Policy

typescript/src/models/policy.ts defines only PolicyReference: 
interface PolicyReference {
  readonly name: string;
  readonly version: string;
  readonly schemaVersion: string;
}
This is what appears on BusinessTransaction.policy — a lightweight pointer to a policy, not the policy itself. It is not the same shape as Policy from @parmana/policy (used by PolicyApi.validate()): 
interface Policy {
  policyId: string;
  policyVersion: string;
  schemaVersion: string;
  signalsSchema: Record<string, string>;
  rules: PolicyRule[];
}
Same underlying concept, two different field names for identity (name/version vs. policyId/policyVersion) and two different amounts of detail (a reference vs. a full evaluable definition). Don’t use one where the other is expected.

​
Override has drifted from the canonical domain model

typescript/src/models/override.ts declares: 
interface Override {
  readonly overrideId: string;
  readonly businessTransactionId: string;
  readonly authorityId: string;
  readonly reason: string;
  readonly approvedAt: Date;
}
The canonical domain type (packages/shared/src/domain/override.ts), which is what OverrideService.create() (packages/runtime/src/services/override-service.ts) actually constructs, is: 
interface Override {
  readonly overrideId: string;
  readonly businessTransactionId: string;
  readonly approvedBy: string;      // not authorityId
  readonly reason: string;
  readonly justification?: string; // missing from the SDK model entirely
  readonly approvedAt: Date;
}
If you ever decode a real Override from the server through this SDK type, authorityId will be undefined (the field on the wire is approvedBy) and justification won’t be represented at all. This is moot today in one sense — see Guides → Human Override — there is currently no REST endpoint or SDK method that creates or retrieves an Override at all, so this model is unreachable from either SDK in practice. It only matters if you construct one by hand or read it off a GET /trust-records/:id response’s overrides array directly.

​
Field types

Timestamps are typed Date throughout these models (issuedAt, createdAt, verifiedAt, evaluatedAt, startedAt, approvedAt, submittedAt). Since HttpTransport deserializes responses with a plain response.json() call (typescript/src/transport/HttpTransport.ts) with no custom reviver, these actually arrive over the wire — and get typed by TypeScript — as strings at runtime, not Date instances, despite the interface declarations. Don’t call .getTime() or other Date methods on these fields without constructing a Date yourself first.

APIs

Methods that accept and return these types.

ParmanaClient

The top-level entry point.

Concepts

The domain concepts these models represent.

Python SDK

The equivalent Python models.