Compliance Decorators

Compliance decorators declare audit, privacy, and data-governance constraints as semantic metadata. These declarations can be consumed by logging pipelines, database layers, and export tooling.

@tAudit#

tAudit records an application action in an immutable audit trail.

import { tAudit } from '@axiljs/decorator'
 
@tAudit({
  action: 'user.deleted',
})
async deleteUser(id: string) {}
 
@tAudit({
  action: 'funds.transferred',
  compliance: ['SOC2', 'PCI-DSS'],
  sensitivity: 'high',
})
async transferFunds() {}

Options#

@tSensitive#

tSensitive classifies a property under a specific sensitivity classification.

@tSensitive('PII')
email: string
 
@tSensitive('PCI')
cardNumber: string
 
@tSensitive('PHI')
diagnosis: string

Supported classifications include:

@tRedact#

tRedact prevents a property value from appearing in logs or outbound responses.

@tRedact()
password: string

For controlled masking, specify a redaction strategy:

@tRedact({
  strategy: 'mask',
  visibleChars: 4,
})
cardNumber: string

For example, the masked value can appear as:

****1234

Strategies#

@tRetention#

tRetention declares a data-retention policy for an entity or property.

The decorator allows retention requirements to be represented as metadata rather than embedding retention logic directly into application code.

@tRetention(/* retention policy */)

The source specification defines tRetention as the decorator for retention policy declarations, but does not specify its option schema in this documentation set.

Combining Compliance Semantics#

Compliance decorators can be composed to describe both what data represents and how it should be handled.

class PaymentRecord {
  @tSensitive('PCI')
  @tRedact({
    strategy: 'mask',
    visibleChars: 4,
  })
  cardNumber: string
}

An audit operation can separately declare its governance requirements:

@tAudit({
  action: 'funds.transferred',
  compliance: ['SOC2', 'PCI-DSS'],
  sensitivity: 'high',
})
async transferFunds() {
  return this.paymentService.transfer()
}

This separates compliance intent from the implementation of logging, redaction, storage, or export behavior.

Reference#

Compliance decorators are semantic declarations. Their metadata can be consumed by independent infrastructure components such as logging pipelines, database layers, and export tooling rather than requiring compliance logic to be embedded into every business method.