Attested Intelligence
Contact

Policy Artifact

Sealed, cryptographically signed governance objects that define constraints, permissions, and enforcement rules for attested subjects.

What is a Policy Artifact?

A policy artifact is an immutable governance object that defines what an attested subject is permitted to do. Once sealed, it cannot be modified—only superseded by a new version. This creates verifiable, auditable governance that can be proven to third parties without trust in any infrastructure.

Terminology Note: Policy Artifact corresponds to the "Attested Governance Artifact" terminology in our patent filing. Patent-pending filing (details available on request).

Sealing Mechanics

Policy artifacts are sealed through a deterministic, cryptographic process:

1

Canonicalization

The policy document is transformed into a canonical form—deterministic JSON with sorted keys, consistent whitespace, and normalized encoding. This ensures identical policies always produce identical hashes.

2

Commitment Hash

BLAKE2b-256 hashes the canonical form, creating a unique 256-bit fingerprint. Any change to the policy—even whitespace—produces a completely different hash.

hash = BLAKE2b-256(canonical_policy)
3

Signature

The issuer signs the hash with their Ed25519 private key. This binds the policy to the issuer's identity and proves they authorized this exact policy content.

signature = Ed25519.sign(hash, private_key)

Enforcement Semantics

Allowed Actions

Actions matching policy permissions execute normally. A signed receipt is generated proving the action was policy-compliant.

Receipt: ALLOWED

Blocked Actions

Actions violating policy constraints are blocked before execution. A signed violation receipt records the attempt.

Receipt: BLOCKED

Conditional Actions

Some policies require additional approval or rate limiting. The sentinel queues the action until conditions are met.

Receipt: PENDING → ALLOWED/BLOCKED

All receipts are cryptographically signed and added to the continuity chain, creating a tamper-evident audit trail.

What Receipts Prove

  • Temporal Binding: The exact policy version that was in effect when the action occurred
  • Decision Record: Whether the action was allowed, blocked, or required conditions
  • Action Details: What was attempted, by whom, and with what parameters
  • Chain Position: Where in the continuity chain this receipt sits, preventing reordering
  • Verifiable Authority: Cryptographic proof linking to the policy issuer

Try It

See policy artifact sealing in action with our interactive demo. Enter a policy, see the canonicalization, and generate a sealed artifact.

Open Policy Artifact Demo →

Claims Status

FeatureStatusEvidence
Policy canonicalizationImplementedlib/site.ts
BLAKE2b-256 hashingImplementedschema/v1
Ed25519 signingImplementedschema/v1
Sentinel enforcementSpecifiedProtocol spec
Policy versioningRoadmapPlanned

Frequently Asked Questions

What is a policy artifact?

A policy artifact is a sealed, cryptographically signed governance object that defines the constraints, permissions, and enforcement rules for an attested subject. Unlike configuration files that can be changed, policy artifacts are immutable once sealed—creating a verifiable, tamper-evident governance record.

How are policy artifacts different from configuration files?

Configuration files are mutable and their history is often unclear. Policy artifacts are cryptographically sealed, immutable, and linked to a continuity chain. You can prove what policy was in effect at any time, who authorized it, and verify it hasn't been altered.

How are policy artifacts sealed?

Sealing follows three steps: (1) Canonicalization—the policy is formatted deterministically to ensure consistent hashing; (2) Hashing—BLAKE2b-256 creates a unique fingerprint; (3) Signing—Ed25519 signature binds the policy to the issuer's key. The result is an immutable governance object.

What can a policy artifact contain?

Policy artifacts can define: allowed actions and capabilities, resource access limits, rate limits and quotas, required approvals or conditions, blocked actions and prohibited patterns, audit requirements, and references to other policies for composition.

What happens when a policy is violated?

The enforcement sentinel blocks the violating action before it executes. A signed violation receipt is generated containing: the attempted action, the policy constraint violated, timestamp, and cryptographic proof. This receipt is added to the continuity chain as permanent evidence.

Can policies be updated?

Yes, but updates create new policy artifacts—the original remains sealed and immutable. Policy versions are linked, creating a verifiable history of governance changes. Active policies can reference which version is currently bound to a subject.

How do policy artifacts support multi-party governance?

Policy artifacts can require multiple signatures (multi-sig), reference parent policies for hierarchical governance, and include delegation rules. This enables complex governance structures like organizational hierarchies or consortium agreements.

Can policy artifacts be verified offline?

Yes. All verification is cryptographic and requires no network access. Given the policy artifact, its signature, and the issuer's public key, any party can verify authenticity and integrity without contacting any server.

Related Resources

GlossaryWhat is a Policy Artifact?TechnicalTechnology OverviewMechanismContinuity ChainInteractivePolicy Artifact Demo