Technical Memorandum

Executive Summary

Prooflane is a system that records decisions in a consistent format. Each record includes who acted, which rules applied, what evidence was used, and what changed. The record is used for audit, enforcement, and integration. If you understand the record, you understand how the system works.

i. Decision Record Architecture

System state resolves to the record

                  Decision Record
        ┌────────────────────────────────┐
        │ Payload                        │
        │ Attribution                    │
        │ Policy Context                 │
        │ Evidence References            │
        │ Integrity Metadata             │
        └────────────────────────────────┘

The decision record is the atomic unit of the system.

Each decision event becomes one structured record. The record states what was decided, who took part, which rules applied, and what evidence supports the outcome.

The system is record first. Screens and workflows help create and read records, but they do not define system state.

Every record follows the same schema. Attribution, policy context, and evidence links are required fields, not optional notes.

Records are linked so the system can show sequence, dependency, and replacement between decisions.

Old states are kept. The system appends new states and does not overwrite prior records.

ii. Identity and Attribution Model

All actions bind to identity

Actor → Role → Decision Record

The system assigns identity within the decision record.

Every action must point to a known person or system process. Anonymous actions are rejected.

Identity and role are stored separately. Identity says who acted; role says how they were involved.

Attribution is structured. The system tracks origin, approval, modification, and execution as separate actions.

Identities use stable IDs, so attribution remains reliable across time and across linked records.

No state change is allowed without attribution.

iii. Policy Governance Frame

Policy is encoded and applied within the record

Policy Definition → Policy Application → Decision Record

The system applies policy at the level of the decision record.

Each decision must pass defined rules. Those rules are encoded as machine-checkable conditions.

The record stores policy context: which policies applied, which version was active, and how that affected the outcome.

Policy definitions live separately. Records reference them and store application results.

Compliance must be shown in structured data, not free-text claims.

Policy is time-bound. Later policy updates do not rewrite earlier records.

iv. Immutability and Evidence Contracts

Records persist, changes append

Record v1 → Record v2 → Record v3
(no overwrite)

The system preserves decision records as stable objects.

After a record is finalized, it is not edited in place. Changes create a new state or a new linked record.

The system keeps the full state history so every transition can be reviewed later.

Evidence is attached through explicit references, not assumptions.

Evidence is preserved as it existed when the decision was made.

v. System Integration Boundaries

External systems operate at the record boundary

External System ⇄ Decision Record ⇄ Prooflane

The system integrates through the decision record.

External systems can create, read, and reference records, but they cannot directly touch internal workflow state.

The record schema is the integration contract. Inputs must match that schema to be accepted.

External inputs still go through attribution checks, policy validation, and evidence binding.

Outputs are structured records, not only summaries.

Versioned contracts control compatibility, so integrations do not break silently.

Conclusion

The whole system is built around one object: the decision record. State, attribution, policy, evidence, and integration all pass through it. If every action resolves through that object, the system stays consistent and auditable.