Make payment infrastructure
Agentic Ready.

[S] FDE shall translate a named payment-infrastructure outcome into one testable journey and agreed integration boundary; work with the customer’s APIs, controls, people and operating constraints; build or adapt the smallest useful capability; prove adverse and happy paths; and hand off ownership, evidence and rights-cleared learning. Discovery may conclude “configure an existing feature,” “use a documented interface,” or “do nothing.” A strong platform distribution hypothesis helps prioritization but is not evidence of deployment or adoption. [v0.1 §01; Playbook Part I §1]

A customer may accept and operate a successful FDE deliverable without adopting any or all of Decentra’s proposed six-layer stack. Do not condition contractual FDE acceptance on platform purchase unless an explicit signed acceptance term lawfully makes a specific product component part of the FDE scope; even then record delivery acceptance separately from later adoption, recurring revenue and merchant outcomes. No pilot, demo, protocol adapter, patent thesis, repository or signed services SOW by itself establishes production certification, patent grant, live network status, executed license, or merchant distribution. No custody, regulated role or irreversible payment authority is assumed. [v0.1 §01; Playbook Part I §1; Phase 1 §§1,7]

[C] Implementation fees, recurring platform licensing and usage fees are available models, not default commitments. If discovery is subsidized or exploratory, record the funding source, decision owner, stop date and independent FDE obligations. Do not discount safety, contractual performance or customer self-sufficiency to accelerate a sale. Prices, margins, cohort conversion, volume, hiring and time-to-launch are not prescribed by this standard; the draft High-case pro forma is not an operating target. [Playbook Part III §7; Funding Report pp. n/a, sections “Implication for Decentra” and “Historical Decentra financing context”; Phase 1 §6]

[S/F] Assess Agentic Readiness by journey, capability and environment, not by company-wide slogan. For each candidate dimension below record not applicable / unassessed / assessed-gap / assessed-sufficient / implemented / validated / production-ready with a rationale, owner, dated evidence link and remaining risk. “Assessed” means an actual boundary/requirement review; “implemented” means a versioned change exists in the named environment; “validated” means agreed positive and adverse tests passed there; “production-ready” means the separate security, legal/commercial as applicable, customer operational and change approvals are recorded with monitoring and rollback. A customer may be production-ready for one capability and not assessed for another. Do not call a tested sandbox flow production-ready. [v0.1 §§02–03,05; Phase 1 §3]

[S] Intake qualification requires: named sponsor and payment outcome; customer system owner and plausible lawful access/test boundary; a baseline and evidence-shaped success criterion; an economic/reusable case or explicitly bounded exploration; payment actors, fund flow, systems of record, data classes, jurisdiction and likely regulated/network dependencies; and an initial staff/capacity estimate. Record channel/distribution opportunity as a hypothesis until contract and activation evidence exist. If permissions, price, liability, staffing or critical control placement remain unknown, authorize only bounded discovery, defer or decline. An interesting account is not implementation authorization. [v0.1 §02; Playbook Part I §§3–5]

Activity Authorization Policy · A0–A3

PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING. A0–A3 are the sole activity-class rule, not lifecycle stages.

Activity-specific authority. Classify each proposed act at the highest applicable activity class before it begins. No customer sandbox/tenant/system/data access without effective written A1 discovery authorization, and no production tenant/credential or payment-affecting access (even read-only) without separately effective A3; no committed implementation, sensitive access, payment-affecting operation or production-impacting action may occur without documented authority specific to that activity, personnel, purpose, system, data, environment, duration and effect. A prior state, gate exit, meeting, unsigned draft, test result or customer acceptance cannot silently authorize a later act. An A0 conversation needs no universal MSA when limited to public information, Decentra-owned synthetic fixtures and general non-sensitive discussion; any nonpublic material requires express purpose-specific permission and counsel review of whether a binding preliminary instrument is necessary. A1 customer sandbox/tenant/system/data access requires an effective applicable agreement or counsel-approved binding preliminary instrument granting precise discovery rights and effective written customer discovery authorization. A2 committed build requires effective implementation authority and approved deliverables; a preliminary instrument suffices only if counsel confirms it binds the parties for that precise build. A3 is a separate production-access/live release decision, not a consequence of A2 or acceptance. Before Decentra requests, issues, accepts, provisions or elevates a production credential, the issuer/owner must confirm the effective versioned A3 release ID, named person, environment/window/scope and customer production signer/payment authority as applicable. This is an A3 precondition and does not bind a customer issuer absent contract. Unsolicited credentials are not permission: deny use, quarantine/revoke through the owner, preserve grant/revocation evidence and escalate. Every prerequisite marked applicable must be evidenced before the act; an inapplicable control needs a dated rationale and its deciding owner, not an empty cell.

Activity Authorization Matrix

Authorization record and decision. The FDE engagement lead maintains a versioned, access-controlled record per proposed activity and transition, linked from the opportunity/engagement ID and relevant gate artifact. Assign a unique authorization ID and revision; record (1) A-class, precise allowed/excluded acts and disposition (advance / defer / decline / re-charter); (2) applicable binding instrument ID/version, signatories, execution/effective/expiry dates, clause/permission and scope/SOW/deliverable ID, or the A0 public/synthetic basis and any preliminary-permission finding; (3) named customer and Decentra authorities, owner, permitted staff/subcontractors and required consents; (4) environment, systems, data classes, effective security-approved tool-and-data-route ID/classification/destination/training/retention and egress enforcement, credentials and least-privilege level; (5) start, expiry, review and revocation method; (6) security/privacy/regulatory/network applicability and explicit payment/funds effect and authority determination; (7) funding/commercial decision, open risks, exceptions and mitigations; (8) linked underlying evidence and each approver's identity, role, decision, timestamp with timezone, and superseding record. Record refusal and unresolved blockers as well as approvals. A link or summary without effective underlying permission is insufficient. Check current effectiveness at the time of action; no automatic A-state advancement.

STOP and escalation. On expiry, revocation, material change or uncertainty about authority, STOP the affected act immediately; limit/revoke access as appropriate, preserve evidence and record the decision. Material change includes personnel/subcontractor, purpose, scope, data class, tool/AI path, system, rail, jurisdiction, payment effect, price/liability or production exposure. Escalate to FDE lead and the customer's authorized system/data/change/payment authority as applicable, plus Decentra counsel, security/privacy, commercial and technical owners for their domains. Revisit the applicable A-class and Charter/control findings; resume only on a new effective, timestamped activity-specific decision. Do not silently waive a missing approval or treat an exception as a substitute for a binding right, customer consent, legal/network obligation or live payment authority. Exceptions need affected control, scope, reason, mitigation, both applicable authorities, start/expiry, review and rollback; no retroactive authorization.

Gate cross-references, not another stage. At #g0 Intake, record A0 boundaries and permitted investigation, not an access grant. At #g1 Discover, remain in A0 unless A1's instrument, effective written customer discovery authorization and access/data/people controls are effective before any customer sandbox/tenant/system/data access. At #g2 Charter, check A2 implementation terms, scope/deliverables, signers, risk and payment authority before committed work; #g3 Design and #g4 Deliver operate inside that approved boundary and re-charter material deviation. At #g5 Accept, retain customer-witnessed pass/fail and residual-risk evidence for the named FDE scope; acceptance is not release, product adoption or payment authority. A3 requires a separate release record before any live effect, even if acceptance passed. At #g6 Transfer, hand off monitoring, incident/support, runbook and credential disposition within the approved obligations; neither handoff nor A3 grants IP reuse, platform license or perpetual support. Keep every existing gate's produce/exit text and stage number. Link records to #evidence, #control-applicability (notably U-02, U-03, U-07, U-09 and U-11; applicable C rows after trigger/owner/counsel review), #roles and the open decisions for phase-specific paper and production signers.

Incident route. Suspected incidents are escalated promptly internally to Decentra security/incident lead and FDE engagement lead, with preservation and containment; the existing proposed within-one-hour internal objective is not a ratified universal external clock. The incident lead and counsel use the actual contract/regulatory trigger-and-recipient matrix to decide external notification, timing and authorized sender with the customer counterpart as applicable. A field worker's internal escalation is not unilateral customer, bank, network or regulator notice.

Each stage requires an identified Decentra DRI, named customer counterpart where relevant, dated artifact, unresolved-risk list and recorded exit (advance / defer / decline / re-charter). A gate does not imply the next gate; a later change in scope, data class, actor or irreversible effect returns to Charter and risk review. An approved exception cannot replace an unsigned contract, customer authorization or required legal/network approval. [v0.1 §03]

[F] Name individuals and backups per engagement; one accountable signer per decision. The same person may hold multiple roles if authority is real and conflict is documented. Review is not approval. Escalate disagreement to an executive sponsor before widening scope or assuming risk. [v0.1 §04]

Payment spend authorization and atomic reservation [F; proposed, owner adoption pending]

For a journey whose integration can issue a payment-affecting instruction or cause a funds effect, before each such instruction or effect, the issuing boundary MUST verify current, unexpired and unrevoked buyer delegation/consent for this actor, agent identity and specific intent, effective A3 live/payment authority where live, applicable policy version, and authoritative available remaining spend envelope. The authorized integration MUST atomically and concurrency-safely check the proposed amount against that remaining capacity and reserve it before allowing the instruction/effect; alternatively retain evidence that the customer's approved system enforces the same checks and atomic reservation at the same instruction/effect boundary. A proposal, credential, prior approval or prior reservation never supplies authority for a later instruction. Scope this requirement to payment-capable journeys; discovery-only work does not require a spend engine and customer/provider-specific reservation semantics must be agreed and evidenced, not presumed.

Missing, expired or revoked authority, unavailable or uncertain remaining balance, exceeded limit, a concurrent race or failed reservation MUST fail closed: deny with no payment instruction or funds effect, preserve an attributable protected append-only or tamper-evident attempt/denial event with actor/agent, intent/correlation, amount, envelope and remaining-capacity observation or UNKNOWN, delegation and policy versions, reason and timestamp, and escalate to named customer payment authority for reconciliation. No human override is permitted without separately documented effective customer authority for that specific act; this rule grants Decentra no blanket payment authority.

Bind each reservation and decrement to the original intent, request and idempotency key; reconcile committed, released or rolled-back reservations with authoritative provider/processor payment status, order system of record and ledger. A timeout or ambiguous result leaves the reservation held or conservatively unavailable while UNKNOWN/HOLD applies; neither local rollback nor release proves no processor effect. No new-key or new-intent retry while unresolved, and an original-key attempt is subject to the provider-specific safe-retry and separate A3 conditions below; before any permitted later instruction recheck current authority and atomically reserve against authoritative remaining capacity without double reservation or double spend. Only release/adjust after authoritative outcome and documented reconciliation, or named customer payment-authority resolution within separately effective authority. A2 synthetic tests must cover missing/uncertain balance, expired/revoked authority, over-limit and concurrent double-reservation plus timeout reconciliation with protected event and no instruction on denial; operational/backend pass evidence and customer approval remain outstanding until actually performed.

Payment unknown-outcome hold and reconciliation [F; proposed, owner adoption pending]

A submitted payment timeout, missing response, or ambiguous processor result is UNKNOWN and HOLD, never a failed payment by inference. Freeze further effects for the same order/intent; do not issue a new payment instruction and do not retry with a new idempotency key. Record original request and key, amount, order/payment/processor correlation IDs, timestamps, actor, authority and release version. Preserve versioned status queries, webhook/processor responses, order and ledger evidence with protected custody, access and retention under approved data controls.

Reconcile authoritative provider/processor status against the order system of record and payment ledger, using original correlation and idempotency evidence; a missing webhook, a local timeout or a stale order flag is not a definitive failure. Document source, status freshness, conflicting records, named decision maker and evidence version. If records conflict or authoritative status cannot be established, remain UNKNOWN/HOLD; escalate to the named customer payment/service authority and Decentra technical/security/support owner (incident route if harmful effect is suspected). Neither a rollback of local state nor a compensating action can undo or presume reversal of a processor effect; any refund/reversal needs separate authority and verification.

Original-key attempt: retry the original request with the same idempotency key only if documented provider-specific semantics and the still-valid dedupe window demonstrate it is safe for that exact operation, with matching request fingerprint and no contrary settled/pending evidence, within separately effective A3 authority for any live effect. Otherwise HOLD and require named human/payment authority resolution with recorded rationale and provider/order/ledger evidence. New-key attempt: prohibited for an unresolved original payment even after a timeout; never use a new key as a blind retry. A final authoritative failure may allow a separate newly authorized intent, not an automatic retry.

Version the incident/decision record and preserve original request/key, source responses, correlation, ledger and order snapshots, custody/access/retention, approvals, changes and superseding status. Release a hold only after documented reconciliation or named payment-authority resolution; if unknown persists, maintain hold, owner, escalation and follow-up. A2 sandbox/synthetic testing does not grant A3: any live retry, refund/reversal or recovery requires the separate scoped A3 live/payment authorization, monitoring and incident/support path.

Data and tools [F; SE-01]. Default proposed posture: customer information stays in the customer-controlled or expressly customer-approved environment. Do not copy, cache, paste or train on it in Decentra infrastructure, personal devices, unapproved external AI/model tools or unauthorized logs. Map API calls, prompts, telemetry, backups, retention/deletion, subprocessors and support metadata before access; apply least privilege, revocable individual accounts and environment separation. Synthetic data and sandbox rails first. Approved use of production data inside the environment is not approval to export it. A technically different environment requires documented customer authorization, signed processing terms where applicable, security review and legal approval; no exception by convenience. No credentials, tokens or cardholder data in notes, demos or general repositories. [v0.1 §05; Playbook Part I §§3,6]

People/confidentiality [F; SE-02/LE-04]. Maintain a named access roster, vetting where required, need-to-know review, onboarding and immediate removal at exit. Before any outsider access require internal authorization, a named roster and need-to-know; counsel records whether contract or regulated-role facts trigger written customer consent. Obtain that consent when triggered, then applicable C-09 diligence and flow-downs before access. If ambiguous, deny access and escalate; do not assume universal customer consent or bind a customer issuer absent contract. Do not name or confirm a customer engagement in public or unrelated private channels without written authorization; authorized customer/Decentra operational channels remain available under confidentiality rules. [Playbook Part I §§4,6]

Authority, security and release [F; SE-03]. An agent proposal is not buyer consent, payment authorization or a regulated decision. Record which human or institution may consent, approve fraud/credit/dispute action, release funds, reverse effects and investigate exceptions; document Decentra’s actual obligations rather than assuming the customer absorbs them. Threat-model replay, privilege escalation, token leakage, double charge, inconsistent order/payment state and operator error. Security testing and remediation evidence precede live effects. Versioned release, customer change authorization, monitoring and rollback are mandatory for production; suspend or re-charter unapproved irreversible effects. [v0.1 §§03,05; Playbook Part I §3]

Incidents [F; SE-04/LE-03]. Any suspected security incident affecting an engagement must be reported immediately to Decentra security and the engagement lead through the documented route, with the playbook’s within-one-hour internal objective proposed for owner approval. Record discovery, preservation, containment and next owner; do not wait for proof or contact outsiders on one’s own authority. The security incident lead and counsel apply the customer-specific contract/regulatory matrix to determine if, when and by whom any external notice is due. A four-hour disruption condition, 36-hour bank notice, 72-hour service-provider notice and 30-day duties are not one interchangeable deadline and must not be declared universally applicable here. [Playbook Parts I §4, IV; Phase 1 §4 L5]

Paper and applicable flow-downs [L]. Before a phase that creates external obligations or sensitive access, the engagement lead must obtain the specific signed authorization and counsel/security applicability record. Proposed modular architecture: relationship MSA (or approved equivalent) and engagement SOW; DPA if processing roles/transfers require it; Security Addendum where controls/assurances must be incorporated; AI Addendum where model use, output, training, evaluation or AI liability matters; Payments Regulatory Flow-Down Schedule where card data, network rules, bank/regulated services or client flow-downs are actually implicated. A schedule may attach to an SOW; not every named document is automatically required in every engagement. Counsel determines triggers, signers, client roles and actual clause text, including IP, indemnities, liability, audit/examination, data disposition and notification. The playbook is a study set, not a signed contract or verified legal conclusion. Do not claim PCI validation or network registration without evidence. [Playbook Parts I §5, IV–V; Phase 1 §§4–5]

Exceptions [F; EX-05]. Log affected control, scoped activity/environment, necessity, alternatives, risk, mitigation, approving customer/Decentra authority, expiry, review and rollback. More restrictive applicable law or contract prevails. No exception can retroactively cure unlawful access, absent customer consent, unlicensed IP reuse, unauthorized live funds or a missing required approval. The FDE lead may stop work pending review. [v0.1 §05]

Applicability decision: Before each activity and material change, use the Control Applicability Matrix with the authorization-state record. Category A is intended universal conduct if ratified; Category B is triggered only by actual facts and counsel/customer determination; Category C is an unapproved legal or commercial position. No exception supplies absent contractual rights.

Reuse stop: A generalized design, residual claim or clean-room proposal does not waive executed rights or customer confidentiality. Keep customer-derived materials restricted until artifact-specific IP counsel and security/privacy clearance, then product-owner admission. Use the candidate register; no exception creates missing rights.

Classification for every engagement

“Use the proposed control applicability register alongside each activity-specific A0–A3 authorization record and the seven existing gates. U-01–U-14 are candidate global field rules pending owner adoption, not current Decentra policy; C-01–C-11 require a documented actual customer/activity/data/jurisdiction/contract trigger, counsel and customer-authority determination, and a reasoned not-applicable finding when appropriate; P-01–P-08 remain OPEN negotiating choices without customer effect until internal approval and applicable executed paper. Record owners, evidence, signers, dates, overlay fields and the decision for each relevant gate and material change. Pause unauthorized access, build, reuse or live effects; no exception cures missing rights or consent. Escalate suspected incidents immediately internally, but have counsel and the customer authority determine each applicable external recipient and deadline. Customer FDE acceptance, production release, core reuse, license/usage and publicity each require their own evidence and authority.”

See the detailed 33-row U/C/P control register; retain the legacy ID crosswalk for earlier evidence.

Classification [F/L; LE-01]. Inventory (i) Decentra background IP (pre-existing platform, tools and independently developed materials), (ii) customer background IP, confidential information and data, (iii) foreground created in the engagement, (iv) candidate generalized technology/inventions, and (v) possible residual know-how. Record source, contributor, repository, inputs, dependencies, contract/SOW version, confidentiality and delivery obligation. These categories do not decide title by themselves: the executed agreement and law govern. Preserve Decentra’s pre-existing rights and the customer’s rights; do not promise automatic ownership of all new work for either side. Residual know-how cannot include client trade secrets, protected data, confidential designs or a shortcut around assignment/use restrictions. [Playbook Part I §2, III §1, V §§128–129,135–137; Phase 1 §5]

Flag and review [F/L; LE-02]. Engineers flag a potentially reusable invention to the engagement lead promptly (playbook proposes the week it arises) and document its provenance before further replication. Quarantine client-derived components from shared repositories and other engagements pending counsel’s express, artifact-specific review of ownership, licenses, general-application and residual clauses, restrictions, third-party licenses and confidentiality. Security checks for protected data or secrets; product checks independent usefulness, quality, tests, maintenance and version policy. Only after written legal/security clearance and product-owner acceptance may code or designs enter the core platform. If rights are missing/unclear, keep a restricted client fork or seek a negotiated right; even an independent reimplementation needs counsel review. General lessons may enter a requirements backlog only in a form that does not disclose protected materials. [v0.1 §§01,03–04,06; Playbook Part I §§2,6]

Feedback loop [S/F]. At Discover, Design and Transfer log repeated integrations, blockers, adapters, defects and customer requests with frequency, impact, proposed generalized interface and evidence; label each customer confidential, general observation, rights review, or cleared. Review at a recurring FDE–product triage with legal/security on rights questions. Product owner may reject, defer, sponsor clean independent development, or accept a cleared item into the roadmap with an engineering owner, tests, versioning and support. Track actual reuse in a second permitted context; do not equate product feedback with reuse permission or a license sale. [v0.1 §§01,03 gate 06; Playbook Part I §1]

[S/F] Measure without inventing universal targets. Delivery measures: intake-to-charter, first reproducible test, time to validated readiness for selected capabilities (start: agreed baseline; end: documented validation), acceptance completion/pass/fail and exceptions, successfully approved production deployments (count only release approvals), incident/escaped defect and recovery outcomes, support load, handoff checklist and demonstrated customer self-sufficiency against agreed scope. Productization measures: cleared integration coverage (reusable requirements actually implemented and rights-cleared), second-customer reuse with separate permission and reduced repeated engineering effort against comparable baselines. Commercial measures: actual FDE fees/cost, signed platform licenses, realized usage revenue, renewal, downstream merchant enablement when attributable and measurable. Keep denominator, period, environment, data provenance and confidence alongside each number; do not label FDE services as software ARR without the finance definition and contract basis. Never report modeled workbook outputs or an unverified partnership as actuals. [v0.1 §06; Funding Report “Implication for Decentra”; Phase 1 §§6–7]

Authorization-state evidence

Retain the instrument and scope version, state and allowed activity, named owners/personnel/subcontractors, approved systems/data/tools/access duration, applicability findings, payment/risk authority, decision signers with timestamp, expiry/revocation and stop/re-charter outcome. Link each record to activity states and control IDs; a summary without underlying permission is insufficient.

Productization candidate record: Track confidential source, provenance, contracts/permissions, confidentiality, tests, version/maintenance owner, four-way disposition, rationale and permitted second-context reuse separately from customer acceptance and commercial evidence. Open the blank register and procedure.

E / Blank Payroc overlay template

Every value is TBD — requires customer confirmation; evidence/approval is empty, not consent. Separate review template · CSV.

[O] Each customer gets a separate versioned overlay citing the approved global standard version (or this proposed version explicitly as nonbinding working guidance). It specifies real parties, jurisdiction/regulated role, journey, systems, paper, approvals, scope, readiness dimensions, tests, operational owner, commercial status and any stricter controls. It may request a time-limited exception through the global process, but cannot silently delete a global gate. A customer-specific promise never becomes a universal rule without owner review and version change. The proposed Payroc field template is in Part E; it contains no Payroc assertions. [v0.1 §07]

[A] Activation requires named executive sponsor, FDE practice owner, product owner, counsel and security/privacy reviewer; approval of the mission, decision matrix, incident coverage, IP protocol, contract applicability and evidence repository; finance review of commercial metrics; and a dated approval record. Review active gates and blockers regularly; inspect acceptance and incidents at handoff; revise with a reason, owner, effective date and migration guidance. Until activation this remains DECENTRA FDE OPERATING STANDARD v1 — PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING. Publishing any derivative requires a separate confidentiality, claims and owner approval decision. [v0.1 §08; Phase 1 §§4,9]

Release-candidate governance, not ratification

GO-01 remains OPEN. Before activation record exact approved version/hash, signers across executive, legal, security, finance, product and FDE domains, effective date, distribution/access boundary, migration/review owner and evidence repository. This Phase 3 private Foldy release candidate is prepared for leadership review only, not public upload or policy adoption; the different pre-Phase3 Phase 2 v1 bytes were observed publicly accessible at the Pages root on 2026-10-18. No publicity approval or public deployment of this candidate follows. See C approvals and G claims.

Targeted operating directions (A)

The eight core sections and seven stage gates remain intact. Review the separate A directions artifact and its CSV alongside the integrated B–G package; none is ratified.

P3-RC1 bounded governance and publication hold

CH-16–CH-25 remain OPEN proposals; CH-25 records a verified owner-directed private hosting transaction, not multi-role policy adoption. F-10 still assigns the executive sponsor, security owner and publication/deployment operator to decide containment of the existing public Phase 2 exposure and authorize or deny external publication of this exact Phase 3 version. The dated receipt supports separation for this private upload only, not future isolation or owner/security signoff. Before ANY public release or further external distribution, obtain version-specific claims/owner/security authorization. Do not deploy public Pages from this private review copy.

Canonical evidence: classify customer delivery fees separately from platform license and realized usage; modeled pro forma and provisional v0.1 are not actual receipts or current policy. Redact restricted source amounts, identifiers and raw customer material from public claims. Record exact proof, period, version and publication permission. Ask counsel/customer authority conditionally whether Bank Service Company Act service/role/data facts or Visa/Mastercard role/rail/network rules apply; UNKNOWN remains pending rather than N/A. UNKNOWN/HOLD payment results require status-source reconciliation and original-key discipline, not blind or new-key retry; U-10 denial/attempt evidence is protected and attributable. Phase3 trace/defect disposition belongs in pre-live and post-live acceptance evidence, not an automatic A3 gate.

Change log · Open decisions · Activity matrix · Candidate template.

Policy status is separate from public accessibility

Document states are Draft, Private Release Candidate, Approved and Superseded. This exact Phase 3 candidate is Private Release Candidate — Owner Approval Pending, not effective policy. Hosting/exposure is a separate, version- and date-specific observation. At 2026-10-18T18:39:35Z a public Pages root sample returned HTTP 200, 150820 bytes, SHA-256 36914d8717617b003a743543900d32e7258bfdeb865e427ca06b9eb74055198a, matching the frozen pre-RC2 predecessor. A later 2026-10-18 read-only root sample returned HTTP 200, 201747 bytes, SHA-256 d2e1589ebb41fd2dfea726a806004732c148f8040d5eb8190809b3e2b06e7581, byte-matching the frozen Phase 2 private source-index.html recorded in baseline-inventory.json. Thus the pre-Phase3 Phase 2 v1 index was publicly accessible at the sampled root despite project metadata publicationState=unpublished and pending owner approval; the 150820-byte observation is an earlier different version, not the current sampled root.

The Phase 3 candidate is now uploaded to this existing private Foldy project for leadership review. The Open Design file-upload route is separate from its explicit Cloudflare Pages deploy route; a dated post-upload public sample still served the earlier 201747-byte Phase 2 snapshot, while the private raw index returned the Phase 3 candidate. This bounded readback does not prove future isolation, publication authorization, ratification or production authority. GO-01 and EX-04 remain OPEN; do not invoke the public deploy route. See the dated private/public hosting receipt and historical status companion.