Engineer
Constitution

Purpose of This Constitution

This document governs the engineering of all Reconstructography software. It exists because software is not neutral. Every architectural decision, every data model, every interface choice embeds assumptions about what matters and what doesn't. The Engineer Constitution makes those assumptions explicit — and holds them to the same standard as the Canon that governs the discipline itself.

Engineers who build Reconstructography software are not building a product. They are building an instrument of truth. That distinction changes everything.

The Relationship Between Software and Methodology

The software exists to implement the methodology — not replace it. This is the foundational principle of all Reconstructography engineering.

The methodology is the Canon. The software is the tool. When the tool and the methodology conflict, the methodology wins. No feature, no optimization, no user request overrides the Canon. Engineers who discover a conflict between a proposed feature and the Canon are required to escalate it — not implement it and hope no one notices.

The software must never make it easier to violate the Canon than to follow it.

Evidence Integrity

Evidence is the foundation of Reconstructography. The software must treat evidence with the same reverence the methodology demands.

Evidence entered into the system must be preserved in its original form. The system must never silently modify, compress, or discard evidence. Every transformation applied to evidence — format conversion, OCR, AI analysis — must be logged with full provenance, including what tool was applied, when, and what the output was.

The original evidence and any derived representations must be kept distinct. A derived representation is never a substitute for the original. If the original is unavailable, that absence must be clearly documented.

Confidence and Provenance

Every claim in the system must carry a confidence level and a provenance chain. These are not optional metadata fields — they are structural requirements.

Confidence levels must be calculated from evidence quality and quantity, not inferred from user preference or narrative convenience. The system must make it easy to assign honest confidence levels and difficult to inflate them.

Provenance chains must be unbroken. Every claim must trace to its source evidence. If a claim cannot be traced, it must be flagged as unverified — not silently accepted. The system must never allow a claim to float without a source.

Contradictions Must Be Preserved

The system must never resolve contradictions automatically. When two pieces of evidence conflict, both must be preserved and both must be visible. The system may flag the contradiction, surface it for human review, and suggest possible resolutions — but it must never choose one over the other without explicit human decision.

A system that silently resolves contradictions is not a reconstruction tool — it is a narrative generator. That is not what we are building.

Contradiction flags must be prominent, not buried. A practitioner who misses a contradiction because the interface hid it has been failed by the software.

AI Assists. Humans Decide.

AI may be used to assist in evidence organization, pattern recognition, contradiction detection, confidence scoring, and search. AI may not be used to make interpretive conclusions about human character, assign final confidence levels, or generate narrative claims that are presented as reconstruction output.

Every AI-assisted action must be clearly labeled as AI-assisted. The practitioner must be able to see what the AI did, why it did it, and what evidence it used. AI outputs must be presented as suggestions, not conclusions.

The system must make it structurally impossible for AI output to be published as reconstruction output without explicit human review and approval. This is not a UI preference — it is an architectural requirement.

Human Dignity in Data Architecture

Every data model in the system represents a human being or a human life. The architecture must reflect that.

Personal data must be stored with the minimum necessary detail. Data that is not required for reconstruction must not be collected. Data that is no longer needed must be deletable — and deletion must be complete, not cosmetic.

The system must never make it easy to reduce a human being to a data point. Interfaces that display information about subjects must be designed to convey humanity, not just data. A subject is not a record. The architecture must remember that.

Transparency and Auditability

The system must be auditable. Every action taken in the system — evidence intake, confidence assignment, narrative generation, publication — must be logged with a timestamp, a user identifier, and a description of what was done.

Audit logs must be immutable. They must not be editable by any user, including administrators. The history of a reconstruction is itself evidence — and it must be treated as such.

Practitioners must be able to export a complete audit trail for any reconstruction at any time. This export must be human-readable, not just machine-readable.

Security and Access Control

Reconstructions often contain sensitive personal information. The system must protect that information with the same rigor it applies to evidence integrity.

Access control must be granular. A practitioner must be able to share a reconstruction with specific collaborators without exposing all reconstructions. A subject or their family must be able to request access to a reconstruction about them.

Data in transit must be encrypted. Data at rest must be encrypted. Encryption keys must be managed with appropriate security practices. Security audits must be conducted regularly and their findings documented.

Open Standards and Portability

Reconstructions must be portable. A practitioner must be able to export their complete reconstruction — all evidence, all metadata, all provenance chains, all confidence levels, all narrative output — in an open, documented format.

The system must not create lock-in that prevents practitioners from moving their work. The evidence belongs to the practitioner and the subject — not to the platform.

Where possible, the system should use open standards for data storage and exchange. Proprietary formats must be documented and export tools must be maintained.

Revision and Versioning

Reconstructions change as new evidence emerges. The system must support versioning of reconstructions — preserving the complete history of every change, including what changed, when, who made the change, and what evidence prompted it.

Version history must be immutable. A practitioner may add to the history but not erase it. The ability to see how a reconstruction evolved over time is itself a form of evidence about the reconstruction process.

Published reconstructions must clearly indicate their version and date. When a reconstruction is updated after publication, the update must be documented and the previous version must remain accessible.

The Engineer's Oath

Engineers who build Reconstructography software commit to the following:

I will build software that serves the methodology, not software that replaces it. I will preserve evidence with the same care I would want applied to evidence about my own life. I will make contradictions visible, not convenient. I will ensure that AI assists and humans decide — always. I will build for human dignity, not just for user engagement. I will document what I build, why I built it, and what I chose not to build. I will escalate conflicts between proposed features and the Canon rather than resolve them silently. I will treat the audit log as sacred.

This oath is not a formality. It is the standard against which all engineering decisions are measured.