Version 0.1 — Ratified

Ratified by the Foundation Owner on 2026-08-22. This publication is subordinate to and specializes the TXFR Product Constitution v0.1 (Article XIV and applicable provisions), the TXFR Capital Intelligence Standard v0.1, and the TXFR Atlas Intelligence Constitution v0.1. It is published at https://foundation.txfr.cc/architecture, effective 2026-08-22.

Document Status

Preamble — Where Constitutional Promises Meet Persistence

A constitution can say that Atlas never becomes the source of Operational Truth. A standard can say that missing inputs produce a Degraded State rather than fabricated precision. Neither promise survives contact with implementation unless something decides, concretely, which system is authoritative for which fact, how long anything is kept, what happens when two sources disagree, and how a Goal's history survives the person managing it changing. This publication is that architecture.

It is deliberately the last of the four originally scoped Foundation v0.1 publications, because it closes deferrals the other three left open on purpose: the Product Constitution's implementation-neutral Data Authority Principle, the Capital Intelligence Standard's unset freshness thresholds, and the Atlas Intelligence Constitution's undefined Authorized Correction pathway and Parent-to-Adult data-transition mechanics all resolve here.

Constitutional Question

What data, provenance, lifecycle, authority, and persistence architecture must exist so TXFR's constitutional promises remain true in implementation?

Architectural Principle

The smallest architecture capable of preserving constitutional truth, not the most sophisticated architecture imaginable.

Article I — Constitutional Authority, Purpose, and Scope

Authority

This Architecture is subordinate to the TXFR Product Constitution v0.1, in particular Article XIV (Data Authority Principle) and applicable provisions concerning Goals, Holdings, Asset Roles, Capital Flow Rules, Milestones, Decision History, Capital Intelligence, Atlas, Human Decision Authority, Execution Authority, Appropriate Reliance, and Parent-to-Adult Continuity. It is further subordinate to the TXFR Capital Intelligence Standard v0.1 and the TXFR Atlas Intelligence Constitution v0.1, whose concepts it consumes without redefinition. Nothing in this Architecture reopens a ratified constitutional or publication-level decision.

Purpose

This Architecture establishes the data, provenance, lifecycle, and authority structures necessary for TXFR's constitutional promises to remain true in implementation — closing the deferrals left by the three prior publications regarding authoritative-source hierarchy, provenance, freshness, retention, Decision History versus transaction truth, Companion Memory persistence, the Authorized Correction pathway, auditability, reproducibility, and Parent-to-Adult data authority transition.

Scope

This Architecture governs: architectural layering and authority boundaries; data classification; authoritative source hierarchy and conflict handling; provenance and time semantics; market-data freshness and bounded historical retention; the database lifecycle principle; holdings and asset identity; Goal-scoped context; derived-intelligence and Decision History persistence; Recorded, Verified, and Reconciled Action; Atlas output and Companion Memory persistence; the Authorized Correction pathway; immutability, supersession, auditability, reproducibility, and versioning; invalidation and recalculation; privacy and data minimization; Goal history lifecycle; Parent-to-Adult authority transition; authorization boundaries; deletion; provider independence and degraded operation; scheduling and evaluation principles; notification-as-derived-delivery; baseline security principles; and the MVP/future architecture distinction.

Scope Boundary

This Architecture does NOT specify SQL, table names, columns, indexes, row-level-security policies, Supabase configuration, API endpoints, cron expressions, queue technology, cloud vendor, LLM provider, embedding model, vector database, frontend state management, UI design, exact retention day-counts, exact freshness thresholds, or a specific market-data provider. It establishes the architecture those choices must satisfy; it does not make those choices.

Article II — Governing Heritage

This Architecture applies the following Telesty Foundation™ publications, incorporated by versioned reference under Product Constitution Article III:

No authority is incorporated from WO-FND-001, which remains Draft and unapproved within the Telesty Foundation.

Non-Importation Principle

TXFR does not import Telesty's enterprise Context Domain taxonomy, Organizational Discovery apparatus, or multi-industry illustration set merely because they exist. This Architecture specializes only the architectural principles TXFR actually needs: bounded representation, provenance, versioning, and lifecycle discipline.

Article III — Governing Definitions

The following terms are inherited without redefinition from the Product Constitution, the Capital Intelligence Standard, and the Atlas Intelligence Constitution, and are used here in their governed sense: Goal, Asset, Asset Role, Capital Flow Rule, Milestone, Reserve, Strategy Lifecycle, Authoritative TXFR Data, Capital Intelligence™, Atlas™, Decision Authority, Execution Authority, Decision History, Degraded State, Evidence, Assumption, Uncertainty, Confidence, Authoritative Fact, Derived Metric, Capital Intelligence Condition, Materiality Tier, Recommendation Eligibility, Companion Memory, Authorized Correction, Proactive Surfacing, Responsive Explanation, Operational Truth.

This Architecture establishes the following additional terms:

Fact Class — A governed category of Authoritative Fact (e.g., market price, user-entered quantity, Goal target) for which a single Authoritative Source rule applies (Article VII).

Authoritative Source Rule — The governed rule determining what may become authoritative for a given Fact Class. A rule MAY designate a single provider, a provider precedence order, accepted user authority, or an authorized composite or fallback mechanism, but never permits multiple conflicting values to simultaneously hold authoritative status for the same fact.

Normalization / Provenance / Validation Layer — The governed process through which raw external or human input is normalized, validated, given identity resolution and temporal interpretation, attached to a Provenance Record, evaluated against the applicable Authoritative Source Rule, and screened for conflict, before it may be admitted to the Authoritative Data Layer (Article V).

Provenance Record — The minimal governed record of a fact's origin, observed/effective/recorded time, and transformation lineage sufficient to answer where TXFR obtained it and what produced any conclusion derived from it (Article VIII).

Freshness Class — A governed classification of how current a fact must be for a specific intelligence purpose: Current, Aging, Stale, or Unavailable (Article X).

Freshness Requirement — The explicit, testable, and versioned declaration a capability makes of the Freshness Class its calculation requires from a given Fact Class (Article X).

Governed Lifecycle Policy — The required, explicit determination of whether a given category of persisted data is retained, summarized, superseded, archived, or purged (Article XII).

Recorded Action — A capital movement or transaction the user states they performed, preserved by TXFR as the user's own statement, authoritative only as a record of what was reported, not as independent proof of external execution.

Verified Action — A Recorded Action independently confirmed by an appropriate authoritative external integration or source.

Reconciled Action — A Recorded Action subsequently compared against independently authoritative information and brought to a resolved state, which MAY confirm the original record or identify and resolve a discrepancy without rewriting the original record.

Goal Beneficiary — The person for whose future a Goal is being built, who may or may not currently hold management authority over it.

Goal Controller — The person currently authorized to manage a Goal's strategy, holdings, and configuration.

Goal Viewer — A person authorized to view some or all Goal information without management authority.

Invalidation — The governed marking of a Derived Metric or Capital Intelligence Condition as no longer reliably current because a material upstream Authoritative Fact it depended on has changed.

Conflict State — A governed condition in which two or more sources materially disagree about the same fact and no Authoritative Source Rule resolves the disagreement automatically.

Governed Lifecycle Action — A separately authorized deletion, anonymization, detachment, or archival action, distinct from and not prohibited by a record's append-oriented status during ordinary product operation (Article XXI).

Article IV — Architectural Purpose

This Architecture exists to ensure that Goals, Holdings, Asset Roles, Capital Flow Rules, Milestones, contribution plans, Reserve configuration, Strategy Lifecycle state, market facts, historical market context, Capital Intelligence, Goal Trajectory, Decision History, Atlas interpretation, Companion Memory, and Authorized Correction can all be represented, persisted, and reasoned about without violating any constitutional boundary already established.

Non-Goal Principle

This Architecture does not design the application UI, database schema, or any specific implementation technology. It establishes the architecture those designs must satisfy.

Article V — Architectural Layers

TXFR's architecture is intentionally layered so that authority boundaries remain explicit at every stage. Raw input does not become Authoritative TXFR Data merely by arriving; it must first pass through governed normalization:

External Sources / Human Inputs → Normalization / Provenance / Validation Layer → Authoritative Data Layer → Derived Intelligence Layer → Atlas Interpretation Layer → Human Decision → Governed Recorded Outcome

Raw-Input Admission Prohibition

Neither a raw provider payload nor a casual conversational statement becomes authoritative merely by being persisted. Both SHALL pass through the Normalization / Provenance / Validation Layer's governed process before admission to the Authoritative Data Layer. Atlas SHALL NOT become a persistence shortcut around this requirement (Article XX).

Article VI — Data Classes

TXFR data is classified into six governed classes. This classification is architectural, not a database schema.

1. User-Governed Authoritative Data — Goal definition, target, horizon, user-entered holdings, Asset Roles, Capital Flow Rules, Milestones, Reserve Floor, contribution plan, User-Established Strategy State.
2. Normalized External Authoritative Facts — external facts accepted into Authoritative TXFR Data only after passing through the governed Normalization / Provenance / Validation Layer and the applicable Fact-Class Authoritative Source Rule. Examples MAY include supported market price, market-session information, bounded historical market observations, and asset metadata from approved providers, each with preserved provider provenance.
3. Derived Data / Capital Intelligence — current valuation, allocation, drawdown, Goal Trajectory, Milestone progress, Capital Intelligence Conditions, Materiality, Recommendation Eligibility.
4. Decision History — governed record of surfaced Conditions where appropriate, user Decisions, Recorded/Verified/Reconciled Actions, Milestone consequences, resulting Goal-state changes.
5. Companion Memory — conversational-continuity information carrying no financial authority.
6. Audit / Provenance Data — origin, observed time, version, transformation, correction, and authorization records supporting Articles VIII, XXII, and XXIII.

Sufficiency Principle

These six classes are approved and sufficient for Foundation v0.1. This Architecture does not split or add classes speculatively. A future Architecture revision MAY refine the taxonomy if actual product requirements justify it.

Article VII — Authoritative Source Hierarchy

Fact-Class Authority Principle

Authority is Fact-Class specific, not a single hierarchy where one source always wins for everything. A market-data provider MAY be authoritative for current price. The user MAY be authoritative for a manually entered cold-storage quantity. The governed Goal model MAY be authoritative for the Reserve Floor. Capital Intelligence MAY be authoritative for a Derived Metric. Atlas is authoritative for none of these facts merely because it discussed them (Article V).

Each Fact Class SHALL have exactly one governed Authoritative Source Rule at any given time. That rule MAY designate a single provider, a provider precedence order, accepted user authority, or an authorized composite or fallback mechanism — but SHALL NOT permit multiple conflicting values to simultaneously hold authoritative status for the same fact. Application of the rule occurs within the Normalization / Provenance / Validation Layer (Article V), not after admission to the Authoritative Data Layer.

No-Silent-Overwrite Principle

The following conditions SHALL produce an explicit Conflict State or Degraded State rather than a silent overwrite: two sources materially disagreeing; user-entered information conflicting with imported information; a previously authoritative source becoming unavailable; authoritative data becoming stale; or ownership of a fact changing through a governed process. Resolution requires an applicable Authoritative Source Rule, a governed Authorized Correction (Article XX), or explicit escalation — never an automatic, unexplained substitution.

Article VIII — Provenance

Every material Authoritative Fact SHALL carry a Provenance Record, attached during the Normalization / Provenance / Validation Layer (Article V), sufficient to support Appropriate Reliance (Product Constitution Article XI; Atlas Constitution Article XI), answering: Where did TXFR get this? and What information produced this conclusion?

A Provenance Record MAY include: source; source type; observed/reported time; effective time where different; recorded (ingestion) time; freshness status; source-quality or confidence indicator where applicable; supersession reference; correction history; and, for Derived Metrics, transformation lineage back to their material Authoritative Facts.

Minimalism Principle

Provenance SHALL be sufficient to answer the two questions above without becoming an enterprise metadata archive disproportionate to TXFR's actual materiality and audit needs (Article XXII).

Article IX — Time Semantics

Financial information carries multiple relevant timestamps, distinguished only where they serve a real purpose:

• Observed Time — when the source reported or represented the fact.
• Effective Time — when the fact applies economically or strategically.
• Recorded Time — when TXFR persisted the fact.
• Evaluated Time — when Capital Intelligence evaluated a Condition.

Stale-as-New Prohibition

The architecture SHALL prevent a newly recorded old fact from being mistaken for a newly effective financial event. Where Observed Time and Recorded Time diverge materially, both SHALL remain distinguishable in the Provenance Record.

Article X — Market Data Freshness

Freshness is a framework, not a universal minute count. Different intelligence purposes tolerate different Freshness Classes: current valuation, intraday market context, daily Goal review, historical drawdown, and long-horizon Contribution Trajectory do not necessarily require identical freshness.

Freshness Classes

Current, Aging, Stale, Unavailable — the exact thresholds separating these classes are Fact-Class-and-purpose-specific configuration, not Foundation-level text. No numeric threshold is established here, even illustratively, to avoid embedding an accidental Foundation-level market-timing assumption.

Freshness Declaration Principle

Every capability that depends upon freshness SHALL declare an explicit, testable, and versioned Freshness Requirement appropriate to its Fact Class and intelligence purpose. Where a required input does not meet its declared Freshness Requirement, the calculation SHALL produce the corresponding Degraded State (Capital Intelligence Standard Article VI) rather than proceed silently on stale data. Freshness is therefore never left undefined in the actual product, even though this Architecture sets no threshold itself.

This Architecture does not embed provider-specific polling schedules.

Article XI — Market History: Bounded by Purpose

Bounded Retention Principle

Historical data retention SHALL be bounded by demonstrated intelligence purpose. TXFR SHALL NOT retain unlimited high-frequency market data merely because it can. If daily observations satisfy Goal-level intelligence, tick-level history SHALL NOT be required. Where a derived statistic can be reproducibly retained without preserving every raw observation indefinitely, lifecycle reduction SHALL be permitted.

This Architecture establishes, as concepts rather than specific periods: bounded raw history; summarized or derived history; archival where justified; purge; reproducibility; and provider re-fetchability where applicable. Exact retention periods are downstream configuration, not constitutional text.

Article XII — Database Lifecycle Principle

Recurring Persistence Principle

Any recurring process that creates persistent data SHALL have an intentional lifecycle for that data. A new scheduled ingestion, snapshot, history, intelligence, notification, or audit process SHALL NOT be considered architecturally complete until the system has determined whether its outputs are retained, summarized, superseded, archived, or purged.

This principle reflects lessons from prior related operational systems in which recurring persistence produced material storage growth when lifecycle controls were not established alongside ingestion. This Architecture does not specify cron implementation or retention day counts.

Article XIII — Holdings Architecture

Holdings MAY exist across brokerage accounts, retirement accounts, bank/cash accounts, manually tracked assets, external wallets, cold storage, or other supported locations.

Manual-First Principle

TXFR's MVP does not require account aggregation. Manual holdings are first-class: a holding's authoritative quantity MAY come from the user rather than an integration, under the User-Governed Authoritative Data Fact Class (Article VI, VII), admitted through the same Normalization / Provenance / Validation Layer as any other input (Article V).

A holding SHALL distinguish, where applicable: asset identity (Article XIV); quantity; account/location; acquisition and cost-basis information; Asset Role; Goal association; and provenance. Cost basis SHALL NOT be required for a holding to exist; where it is absent, Capital Intelligence Standard Article VI's Degraded State Isolation Principle governs, not a requirement to reject the holding.

Article XIV — Asset Identity

Symbol-Not-Identity Principle

Provider symbols are references to an asset, not necessarily the asset's permanent TXFR identity. A display symbol alone MAY be insufficient to prevent ambiguity. TXFR SHALL be capable of distinguishing an asset through a stable internal identity mapped to provider identifiers where appropriate, so that a future provider change does not silently corrupt asset identity across the system. Identity mapping occurs within the Normalization / Provenance / Validation Layer (Article V).

This Architecture does not design a securities-master database.

Article XV — Goal as Primary Context

Goal Primacy Principle

A holding MAY exist within one or more Goal contexts, but Capital Intelligence SHALL NOT become a detached account-level portfolio engine by accident. Every holding SHALL resolve to at least one governed Goal-scoped context. This Architecture does not mandate multi-Goal allocation mechanics beyond what MVP requires (Article XXXVI), but an implementation in which the Goal is merely a decorative label attached to an account-centric portfolio engine does not conform to this Architecture.

Article XVI — Derived Intelligence Persistence

Persistence-When-Valuable Principle

Persist derived intelligence when persistence provides historical, audit, explainability, or performance value — not by default. A reproducible current allocation calculation MAY be computed on demand without permanent storage. A historically surfaced Milestone-Relevant Condition associated with a user Decision SHOULD be persisted, because its later explainability (Article XXII) depends on it.

This Article establishes the distinction; it does not choose caching, snapshotting, or storage technology.

Article XVII — Decision History and Recorded, Verified, and Reconciled Action

Decision History Contents

Decision History (Product Constitution Article IX) is a first-class governed, append-oriented record (Article XXI). Where applicable, an entry SHOULD link: the relevant Goal; the relevant Capital Intelligence Condition; the Atlas Observation or Recommendation, where one existed; the user's Decision; the resulting Action's status (below); Milestones affected; relevant timestamps; and provenance.

Recorded, Verified, and Reconciled Action

Execution-Truth Boundary

Decision History is not transaction execution history. These three states represent distinct epistemic conditions and SHALL remain distinguishable:

• Recorded Action — an Action the user states occurred. It is authoritative only as a record of what the user reported, not as independent proof of external execution.
• Verified Action — a Recorded Action independently confirmed by an appropriate authoritative external integration or source.
• Reconciled Action — a Recorded Action subsequently compared against independently authoritative information and brought to a resolved state. Reconciliation MAY confirm the original record or identify and resolve a discrepancy.

No-Silent-Rewrite Principle

Where reconciliation identifies a discrepancy, it SHALL NOT silently rewrite history. The architecture SHALL preserve the original Recorded Action, the authoritative evidence that prompted reconciliation, the discrepancy itself, the reconciled result, and appropriate provenance connecting them. This Article does not create transaction-accounting machinery beyond this three-state model.

Article XVIII — Atlas Output Persistence

Governed-Meaning-Over-Raw-Conversation Principle

Not every generated conversational token requires permanent storage. This Architecture distinguishes: ephemeral conversational response (generally not persisted beyond session needs); material Atlas Observation (persisted where Milestone-Relevant or Material, per Materiality Tier); a Recommendation tied to Decision History (persisted with its supporting Condition); the user's Decision (persisted, Article XVII); and Companion Memory (governed separately, Article XIX).

The architecture SHOULD favor retaining governed meaning over unlimited raw conversation, while preserving sufficient history for continuity, auditability, explanation, and user-facing history.

Article XIX — Companion Memory Persistence

Companion Memory (Atlas Constitution Article III, XXI) improves continuity, is not Authoritative TXFR Data, cannot override governed state, and cannot silently become a financial strategy parameter.

Companion Memory SHOULD have: provenance (which interaction produced it); scope (which Goal or user context it applies to); a lifecycle (Article XII); user visibility; and user correction/deletion capability. It SHALL remain separated across people where appropriate (Article XXIX).

Implementation Neutrality

This Architecture does not design vector storage and does not assume embeddings are required. The persistence mechanism is downstream implementation; the governance boundary above is architectural.

Article XX — Authorized Correction Pathway

This Architecture closes the deferral left by Atlas Intelligence Constitution Article XXI by defining the conceptual lifecycle of an Authorized Correction:

User identifies incorrect authoritative state → Atlas/UI may facilitate the proposed correction → authority is verified against the specific governed operation (Article XXX) → the proposed new value is validated → the proposed value passes through the Normalization / Provenance / Validation Layer (Article V) → a governed write occurs into the Authoritative Data Layer → the prior value is preserved or superseded, as appropriate (Article XXI) → a provenance/audit record is created (Article VIII, XXII) → dependent intelligence is invalidated or recomputed as necessary (Article XXV)

Correction-Type Distinction

This Architecture distinguishes correction of an erroneous fact (e.g., a mistyped quantity), an ordinary update to a current strategy parameter (e.g., a revised contribution plan), and a historical amendment (correcting a past record). These MAY require different provenance semantics, but all SHALL pass through the pathway above rather than a conversational shortcut (Article V's Raw-Input Admission Prohibition).

Atlas SHALL NOT become the write path.

This Architecture does not design the UI or the write mechanism's SQL.

Article XXI — Immutability, Supersession, and Governed Deletion

This Architecture avoids both extremes — everything mutable with no history, and everything immutable forever — by classifying records into three conceptual lifecycles:

• Current-state mutable through governed updates — e.g., the current contribution plan or Goal target, updated in place under governed authority.
• Superseded with history — e.g., Asset Role changes or Reserve Floor changes, where prior values remain historically visible because they affect interpretation of past intelligence.
• Append-oriented — e.g., Decision History or audit events, which are not overwritten or mutated during ordinary product operation.

Append-Oriented Scope Principle

Append-oriented means historical records SHALL NOT be silently rewritten or mutated during ordinary product operation. It does not override a separately governed deletion, anonymization, detachment, archival, privacy, or legal lifecycle action (a Governed Lifecycle Action, Article III). No category is rendered permanently undeletable by this Architecture's use of "append-oriented" language. A Governed Lifecycle Action SHOULD preserve appropriate provenance of its own occurrence where policy permits or requires it (Article XXXI).

This Article establishes the conceptual lifecycle, not a database schema.

Article XXII — Auditability

Auditability Principle

For a material historical event, the architecture SHALL make it possible to answer, where applicable: What authoritative facts existed? What was their freshness and provenance? What Capital Intelligence Condition was produced? What did Atlas surface? What Decision did the user record? What changed afterward? Who authorized a correction, and which prior value was superseded?

Proportionality Principle

Auditability SHALL be proportional to materiality and authority. This Architecture does not require forensic retention of every ephemeral calculation (Article XVI).

Article XXIII — Reproducibility

Where governed financial arithmetic is deterministic (Capital Intelligence Standard Article VI), the architecture SHALL support reproducibility: retaining the material inputs, the calculation or rule version (Article XXIV), the Evaluated Time, and the output — or sufficient references to reconstruct them — such that a material Recommendation remains explicable even after rules or inputs later change.

This Architecture does not require every intermediate computational step to be permanently stored.

Article XXIV — Versioning

Rule-Version Attribution Principle

A historical Capital Intelligence Condition SHALL remain attributable to the rule or calculation version that produced it. Atlas SHALL NOT retrospectively reinterpret a past Recommendation as though today's logic generated it. This specializes the historical-intelligence and causality-discipline requirements of the TXFR Capital Intelligence Standard (Standard Article XVIII) and incorporates without weakening the Historical Version Principle established by Capability Intelligence™ Constitution WO-FND-002 Article XIV.

This Article establishes the principle; it does not define software release tooling.

Article XXV — Invalidation and Recalculation

No-Silent-Staleness Principle

Dependent intelligence SHALL NOT remain silently authoritative after an upstream fact on which it depends materially changes. Where a material Authoritative Fact changes, dependent Derived Metrics and Capital Intelligence Conditions SHALL be invalidated, recalculated, or explicitly superseded — never left standing unmarked as though nothing changed.

This Architecture does not specify queue technology or background-job implementation.

Article XXVI — Conflicts

A Conflict State governs situations including: two market sources materially disagreeing; a user-entered quantity conflicting with a later-imported brokerage quantity; a proposed correction conflicting with a newer authoritative record; or stale data conflicting with current data.

Explicit-Conflict-Over-Silent-Resolution Principle

Where an Authoritative Source Rule does not clearly decide the result, the system SHALL prefer an explicit Conflict State or Degraded State over silent, arbitrary resolution (Article VII's No-Silent-Overwrite Principle).

Article XXVII — Privacy and Data Minimization

This Architecture establishes principles consistent with, but not a substitute for, eventual legal and privacy review: minimum necessary data collection; purpose limitation; avoidance of unnecessary raw-conversation retention beyond Article XVIII's governed-meaning principle; avoidance of duplicated sensitive state across systems; authorization-aware access (Article XXX); and support for deletion and archival (Article XXXI).

No-Compliance-Claim Principle

This Architecture does not write a privacy policy and does not claim legal compliance. It establishes an architecture capable of satisfying future legal and privacy requirements without redesign.

Article XXVIII — Goal History Lifecycle

Goals MAY last years or decades. This Architecture recognizes conceptual Goal states — such as Active, Achieved, Archived, and Transferred — only insofar as they are useful, without prescribing a rigid state machine.

Continuity-Without-Permanence Principle

Goal history SHOULD be preserved after achievement where the user wants continuity (Product Constitution Article XV), but not all history is permanently undeletable (Article XXI, XXXI). This Architecture establishes principles for completion, continuation into a new Goal, archival, and user-requested deletion, without making legal retention claims (Article XXVII).

Article XXIX — Parent-to-Adult Transition

This Architecture closes the deferral left by Product Constitution Article XV and Atlas Intelligence Constitution Article XXVI.

Roles

• Goal Beneficiary — the person for whose future the Goal is being built; not automatically the Goal Controller.
• Goal Controller — the person currently authorized to manage the Goal's strategy, holdings, and configuration.
• Goal Viewer — a person authorized to view some or all Goal information without management authority.

Beneficiary-Controller Independence Principle

TXFR SHALL NOT assume Beneficiary equals Controller. For a child's Goal, the parent MAY initially be Controller while the child is Beneficiary.

Governed Transition

No-Automatic-Transfer Principle

Control SHALL NOT automatically transfer merely because a birthday occurs or an age threshold is reached. A governed transition SHALL require: identity verification; authorization; an explicit transfer and acceptance step where appropriate; preservation of Goal history; corresponding privacy-boundary changes; and revocation or update of the prior Controller's permissions.

Memory and History Separation

Private Memory Non-Transfer Principle

When Goal control changes, the architecture SHALL distinguish historical Decisions made by the prior Controller, current authority, Companion Memory associated with each person individually, shared Goal history, and private conversational memory. Goal history MAY transfer with governed Goal continuity; TXFR SHALL NOT automatically expose one person's private Companion Memory to another merely because Goal control transfers.

Ownership Boundary

TXFR tracks Goals and intelligence; it does not itself determine legal ownership of external financial assets. This Architecture does not solve custodial or account-ownership law.

Article XXX — Authorization Boundary

Operation-Specific Authority Principle

Authorization SHALL be evaluated against the specific governed operation, independently of conversational familiarity. Atlas remembering someone does not authorize them (Atlas Constitution Article XXVIII). A valid session does not necessarily authorize every Goal action. Viewing a Goal, changing a Goal target, changing an Asset Role, authorizing a correction, and transferring Goal control MAY each require different authority.

This Architecture does not design role-based-access-control tables.

Article XXXI — Deletion and Historical Integrity

This Architecture avoids both "delete everything" and "retain everything" as default answers. It recognizes, as concepts only, hard deletion, logical deletion, anonymization, detachment, and archival — each a Governed Lifecycle Action (Article III, XXI) — applicable differently to: current Goal data, Decision History, Companion Memory, audit/provenance data, and derived intelligence.

Future-Policy-Compatible Principle

This Architecture allows future legal and privacy policy to determine exact deletion obligations while preserving a coherent technical model capable of implementing them. A Governed Lifecycle Action is never precluded by a record's append-oriented status under ordinary operation (Article XXI).

Article XXXII — External Provider Independence and Degraded Operation

Provider-Adapter Principle

TXFR SHALL NOT become architecturally captive to one market-data provider. An External Provider → Normalized External Authoritative Fact adapter boundary SHALL exist within the Normalization / Provenance / Validation Layer (Article V, VI) so that provider-specific identifiers and payloads do not leak unnecessarily into downstream Capital Intelligence, while source provenance (Article VIII) is preserved. The goal is replaceability, not the pretense that all providers are equivalent.

Graceful Degradation Principle

Where a provider becomes unavailable, the system SHOULD remain useful where possible. Stale market data MAY degrade current valuation, Opportunity Conditions, or Harvesting relevance while Goal target, holdings quantity, contribution plan, and Decision History remain fully authoritative — applying Capital Intelligence Standard Article VI's Degraded State Isolation Principle architecturally.

Article XXXIII — Scheduling and Evaluation

This Architecture establishes principles only: ingestion and evaluation are architecturally distinct; a new market fact MAY trigger or make evaluation eligible; scheduled evaluation MAY occur without a new fact; evaluation results need not always be persisted (Article XVI); and any recurring process that persists data requires a Governed Lifecycle Policy (Article XII).

This Architecture does not choose cron, queues, serverless functions, or polling schedules.

Article XXXIV — Notifications as Derived Delivery

No-Independent-Truth Principle

A notification SHALL NOT become an independent source of financial truth. Every notification SHALL reference a governed Atlas or Capital Intelligence event or Condition. Where the underlying Condition is superseded before delivery and technically detectable, downstream implementation SHOULD be capable of suppressing or updating the stale delivery rather than delivering contradicted information.

This Architecture does not design push infrastructure.

Article XXXV — Security Architecture Principles

This Architecture establishes, at Foundation level only: least privilege; server-side protection of authoritative writes; separation of public market data from private Goal data; authorization before sensitive reads or writes (Article XXX); secrets never stored as ordinary user data; and auditability for material authoritative changes (Article XXII).

This Architecture does not select vendors or specific implementation mechanisms.

Article XXXVI — MVP Architecture and Database Technology Neutrality

MVP Sufficiency

TXFR's MVP SHALL be able to operate with: manual holdings; one or a small number of market-data providers; bounded historical prices; deterministic derived calculations; Goal, Milestone, and Strategy Lifecycle state; Decision History; minimal Companion Memory; Atlas consuming governed intelligence; and no brokerage execution, custody, or automatic capital movement.

Simplicity-First Principle

This Architecture favors the smallest architecture capable of preserving constitutional truth over the most sophisticated architecture that could be imagined. A future Architecture revision MAY expand it when actual product requirements justify doing so.

Technology Neutrality

Vendor Neutrality Principle

This Architecture does not make Supabase, or any other specific database, constitutionally required. It describes relational authoritative state, historical/event records, provenance, access boundaries, and derived intelligence in vendor-neutral terms. It likewise does not require a vector database merely because Atlas exists (Article XIX).

Article XXXVII — Constitutional Relationships

Article XXXVIII — Compliance and Constitutional Boundaries

Conformance with this Architecture is determined by actual data and persistence behavior, not by adopting its terminology.

Substance over Form

Calling an unbounded market-data table a "cache" does not exempt it from Article XI's Bounded Retention Principle. Calling a conversational memory write a "helpful update" does not exempt it from Article XX's Authorized Correction Pathway. Calling automatic control transfer at adulthood a "housekeeping update" does not exempt it from Article XXIX's No-Automatic-Transfer Principle. Calling a raw provider payload "already authoritative" does not exempt it from Article V's Raw-Input Admission Prohibition. Constitutional classification follows what the architecture actually does, not what it is called.

Article XXXIX — Architectural Invariants

1. Every Fact Class has exactly one governed Authoritative Source Rule at a time; no fact is admitted to the Authoritative Data Layer without first passing through governed normalization, validation, and provenance attachment; Atlas is authoritative for none merely by discussing it.
2. Material facts and their derived conclusions carry sufficient Provenance to answer where TXFR obtained them and what produced them.
3. Conflicting sources produce an explicit Conflict State or Degraded State; they are never silently overwritten.
4. Historical market data retention is bounded by demonstrated intelligence purpose, never retained merely because it can be.
5. Any recurring process that persists data has an intentional, explicit lifecycle policy before it is architecturally complete.
6. Decision History is never conflated with independently verified transaction execution; a Recorded Action remains distinguishable from a Verified or Reconciled one, and reconciliation never silently rewrites the original record.
7. Companion Memory never becomes financial authority, and never silently becomes a Capital Flow Rule, Asset Role, Milestone, or strategy parameter.
8. Authoritative TXFR Data is changed only through the governed Authorized Correction pathway, never through a conversational shortcut.
9. Dependent Capital Intelligence is invalidated, recalculated, or explicitly superseded when a material upstream fact changes; it never remains silently stale.
10. A historical Capital Intelligence Condition remains attributable to the rule or calculation version that produced it, and is never retroactively reinterpreted under today's logic.
11. Auditability for a material event is reconstructible, proportional to materiality and authority, never demanding forensic retention of every ephemeral calculation.
12. Goal Beneficiary and Goal Controller are never assumed identical; control never transfers automatically at an age threshold.
13. Private Companion Memory belonging to one Goal Controller is never automatically exposed to a successor Controller merely because control transfers.
14. Authorization is evaluated against the specific governed operation, never inferred from conversational familiarity or session validity alone.
15. TXFR is never architecturally captive to a single market-data provider; provider-specific payloads never leak unnecessarily into Capital Intelligence.
16. Degraded State Isolation applies architecturally: an unavailable or stale source degrades only the intelligence that depends on it, never unrelated authoritative state; every dependent capability declares its required Freshness Class explicitly, testably, and with version identity.
17. Notifications never become an independent source of financial truth; every notification traces to a governed Condition.
18. No specific database, cloud vendor, or vector store is constitutionally required by this Architecture.
19. Conformance follows actual data and persistence behavior, not adopted terminology (Substance over Form).
20. Append-oriented record-keeping prohibits silent rewriting during ordinary operation; it never overrides a separately governed deletion, anonymization, detachment, archival, privacy, or legal lifecycle action.

Article XL — Closing Principle

An architecture is trustworthy not because it stores everything, but because it knows, for every fact it holds, where that fact came from, who is allowed to change it, how long it should exist, and what breaks if it turns out to be wrong.

Closing Constitutional Principle

Authority is governed, not assumed. Nothing is authoritative merely for having arrived. Provenance survives derivation. Retention is bounded by purpose, not convenience. Control transfers deliberately, never by default. This is the architecture beneath TXFR Intelligence calculates. Atlas interprets. The human decides.

Ratification Record

TXFR Data & Intelligence Architecture v0.1 was ratified by the Foundation Owner on 2026-08-22.

Ratification followed: (1) a Draft prepared under authorization specializing Product Constitution Article XIV and applicable provisions, applying the architectural shape of Operational Context Framework™ (WO-FND-003 v1.1.0), and consuming without redefining the Capital Intelligence Standard's and Atlas Intelligence Constitution's concepts; (2) Foundation Owner review approving the Draft in substance; (3) a Ratification Candidate revision incorporating eighteen numbered Foundation Owner decisions — most significantly correcting the architectural layer order so that normalization, validation, provenance attachment, identity mapping, and Authoritative Source Rule application precede any admission to the Authoritative Data Layer, refining the Recorded/Verified/Reconciled Action model with an explicit No-Silent-Rewrite Principle, strengthening the Freshness Declaration Principle without introducing numeric thresholds, correcting Database Lifecycle Principle provenance language to avoid implying TXFR's own prior operating history, and clarifying that append-oriented history never overrides a separately Governed Lifecycle Action such as deletion; and (4) explicit Foundation Owner ratification of the complete Ratification Candidate without further substantive modification.

This publication closes the fourth and final originally scoped TXFR Foundation v0.1 publication. This Architecture is published at foundation.txfr.cc, effective 2026-08-22. See foundation/CHANGELOG.md for the Foundation-level record of this event.

Appendix A — Representative Scenarios (Nonnormative)

These scenarios illustrate this Architecture's rules using generic, fictional placeholders. They establish no universal investment rule, threshold, or asset-specific guidance, per Capital Intelligence Standard Article XX.

A. Manual Cold-Storage Holding. A user records an external cold-storage holding of Opportunity Asset A with no cost basis. The holding passes through normalization and is admitted with no cost basis under the Manual-First Principle (Article XIII); gain/loss remains a Degraded State while current value and quantity milestones remain fully calculable (Capital Intelligence Standard Article VI).

B. Market Provider Unavailable. The provider for Opportunity Asset A's price becomes unreachable. Last price ages past its declared Freshness Requirement into Stale; dependent Opportunity Conditions degrade accordingly, while the Goal's target, holdings quantity, and contribution plan remain fully authoritative (Article XXXII).

C. User Corrects Quantity. A user proposes that a manually entered holding's quantity is wrong. The correction proceeds through the Authorized Correction pathway (Article XX): authority verified, new value validated, normalized and provenance-attached, prior value superseded, dependent allocation intelligence invalidated and recalculated (Article XXV).

D. Material Condition and Decision. A Harvesting Condition reaches Recommendation Eligibility; Atlas surfaces a Recommendation; the user records a partial-harvest Decision as a Recorded Action. Decision History links the Condition, the Recommendation, the Decision, and the Recorded Action (Article XVII).

E. Rule Version Changes. Capital Intelligence's Opportunity Condition logic is revised. A previously produced Condition remains attributable to the prior rule version; it is not retroactively reinterpreted under the new logic (Article XXIV).

F. Parent-to-Adult Transition. A Goal Beneficiary reaches adulthood. Goal Controller status does not silently transfer; a governed transition with identity verification and explicit acceptance is required before control changes (Article XXIX).

G. Private Companion Memory. Following an authorized Goal-control transfer, the prior Controller's private conversational memory does not transfer to the new Controller; shared Goal history does (Article XXIX).

H. Recurring Market Snapshots. A proposed daily market-snapshot process is not considered architecturally complete until its retention, summarization, and purge policy is explicitly defined (Article XII).

I. Provider Replacement. TXFR replaces its market-data provider for Opportunity Asset A. Internal asset identity and historical provenance are preserved across the change via the stable TXFR asset identity, not the old provider's symbol (Article XIV, XXXII).

J. Derived Intelligence Invalidation. A corrected holding quantity (Scenario C) invalidates dependent allocation and Contribution Trajectory intelligence for the affected Goal, which is recalculated rather than left silently stale (Article XXV).

K. Recorded Action Later Contradicted. A user records a Recorded Action describing a harvest and transfer. A later authoritative integration indicates a discrepancy in the recorded amount. Reconciliation preserves the original Recorded Action, the new authoritative evidence, and the identified discrepancy, producing a Reconciled Action without silently rewriting the original entry (Article XVII).

L. Governed Deletion of Append-Oriented History. A user exercises a supported deletion right over historical Decision History entries. The deletion proceeds as a Governed Lifecycle Action, distinct from and not blocked by the append-oriented status those entries carried during ordinary operation (Article XXI, XXXI).