1. Criteria approved
The client approves the rule, authority, fields, version, effective date, evidence, and result handling.
Preserved execution evidence
Decision Artifact
A Decision Artifact records what Pulse evaluated, under which approved criteria, using which authority and inputs, and what result was returned at that moment.
Not just another log
The artifact preserves the decision context required for replay and review.
Traditional logs may show that a service emitted a message. A Decision Artifact should show the approved criteria, authority, relevant conditions, evaluation, result, timing, and integrity controls that governed a consequential action.
- Stable artifact ID and workflow correlation ID
- Workflow, action, environment, and applicable period
- Rule identifier, version, effective date, owner, and approval reference
- Pseudonymous actor or service token and authority requirement
- Required fields, values or hashes, source references, and provenance
- Allow, escalate, or block result with reason codes
- Issued-at time, expiry, nonce, or replay-control state
- Signature or integrity mechanism and validation status
- Reference to the downstream outcome and any governed override
Artifact lifecycle
Keep evidence connected from approved criteria through final outcome.
A useful artifact is part of a controlled lifecycle, not a detached receipt.
2. Event evaluated
Pulse receives the defined context and returns a structured result under the approved criteria.
3. Outcome bound
The consuming service attaches or references the artifact when the action is committed, escalated, or withheld.
4. Artifact validated
An authorized reviewer verifies integrity, timing, version, context, and outcome linkage.
Data minimization
The artifact should not become a new uncontrolled data warehouse.
Preserve stable references, hashes, tokens, reason codes, and provenance where they support the assertion without copying unnecessary personal or confidential data.
- Use pseudonymous actor tokens rather than names across systems
- Reference source records instead of duplicating full payloads
- Store only fields required for the approved condition
- Separate artifact-validation rights from source-record access
- Define retention and deletion by workflow and obligation
- Protect signing keys, mapping tables, and administrative functions
Runtime boundary
The artifact records a shadow evaluation or runtime result. It does not by itself prove that the downstream system honored the result. Outcome linkage and consuming-service controls remain part of the architecture.
Make the decision context preservable before scaling enforcement.
Test the artifact schema against one real workflow, one approved criteria package, and the buyer’s evidence and security requirements.