Organization-wide practice / reusable across partnersDECENTRA FDE OPERATING STANDARD v1 — PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING
Forward-deployed engineering

Make payment infrastructure
Agentic Ready.

Decentra’s specialized FDE practice makes payment infrastructure Agentic Ready through bounded integration, validation and operational transfer. The customer outcome stands on its own; rights-cleared field learning strengthens Decentra’s proprietary platform. Every company inherits the same gates, never another company’s commitments.

LANE A / FDE DELIVERYIntegrate. Validate. Transfer.

One scoped payment journey, independently accepted by the customer.

LANE B / DECENTRA PLATFORMProductize what we may reuse.

Separate rights, product approval and commercial evidence; no automatic adoption.

Partner reality determines the integration. Decentra’s global gates determine how we work.Global core ≠ company deal
DECENTRA FDE OPERATING STANDARD v1 — PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING · v1

Proposed rules are conditional on ratification. Existing signed contracts and applicable law prevail. No customer approval, execution, funding or production status is implied.

A / Proposed global standard · application

Scope. The FDE practice serves Decentra’s agentic-payments mission. It embeds at a payment processor, gateway, acquiring platform, merchant-infrastructure provider, merchant ecosystem, or another explicitly approved payment-infrastructure boundary to remove a measurable impediment to agent-initiated commerce. Work must have a documented connection to payment infrastructure enablement, integration, deployment, validation, or a commercially relevant Decentra platform capability. Generic AI consulting and arbitrary software engineering are outside the mandate. The executive sponsor alone may decide a borderline mission-fit question in writing; such a decision cannot waive security, legal, contract or production gates. This perimeter itself awaits executive approval [EX-01].

Terms. “Customer” means the contracting organization; “partner” includes its named system and business owners, not an asserted strategic partnership. “Journey” means a bounded transaction or supporting workflow in a specified environment, with an actor, system of record, expected outcome and adverse paths. “FDE deliverable” is the contract-defined output of a specific engagement. “Platform milestone” is a separate, evidenced product/license/usage/merchant-activation event. “Approval” means a named authorized signer and retained record, not silence at a meeting. “Evidence” means attributable, versioned records tied to the actual environment and scope. “Production-ready” is a scoped release decision, never a blanket certification of Decentra or a customer.

Rule types. [F] proposed mandatory field conduct; [S] organizational strategy/qualification; [C] proposed commercial position; [L] counsel-controlled legal/contractual matter; [O] customer-specific overlay; [A] unresolved approval. A [C] or [L] item does not bind a customer without the applicable signed document. The register in Part C names ratification owners. Every gate below retains its v0.1 number and minimum bar; the additions tighten, not replace, them. [v0.1 §§01–08; Phase 1 §§2–4]

01

Mandate and boundary

Payments-only FDE enables agentic commerce at payment-infrastructure boundaries; it is not generic AI consulting.

We do

Bounded, embedded delivery

  • Translate a named partner outcome into one testable journey and an agreed integration boundary.
  • Serve processors, gateways, acquirers, merchant infrastructure and ecosystems where work advances agentic-payment readiness. Decline unrelated AI or software engineering work.
  • Work with the partner’s APIs, controls, people and operating constraints.
  • Build or adapt the smallest useful primitive; validate adverse as well as happy paths.
  • Document ownership, evidence and the reusable learning before handoff.
We do not

Unbounded or implied commitments

  • Treat a demo, protocol adapter or patent thesis as production certification.
  • Take custody, regulatory obligations or irreversible payment authority by assumption.
  • Let one partner silently define the global product or another partner’s contract.
  • Equate successful FDE delivery with platform adoption, a signed license, production transaction volume or downstream merchant activation.
  • Call a pilot successful because the slide or UI works while recovery and operations do not.
Two ledgers, always. Track partner-specific delivery separately from reusable platform/IP work. An integration may consume a Decentra primitive; the partner does not adopt the whole technology stack unless that is expressly scoped and validated. FDE deliverables and acceptance stand on their own; licensing, usage and distribution each require separate evidence.
Agentic Readiness is scoped, not a company-wide badge. For each selected workflow capability—agent identity, delegated authority, transaction authorization, spend policy, payment interoperability, risk, audit evidence, recovery or operations—record not assessed, assessed, implemented, validated or production-ready, with environment, owner and proof. Not every engagement needs every capability. Production-ready requires separate release and operations approval.
IP has an explicit rights gate. Identify Decentra background IP, customer background IP and data, engagement foreground IP, generalized inventions and possible residual know-how. Flag candidates promptly; no cross-customer reuse of customer-specific work until contract and confidentiality review, security clearance and product ownership approval. A reusable idea is not a reuse license.

[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]

[F] Maintain two separate ledgers from intake onward:

  1. Customer delivery: signed scope or authorized discovery, owners, fees/obligations, deliverables, acceptance evidence, change requests, operational transfer and support boundary.
  2. Decentra product/commercial: candidate reusable requirements, IP provenance and reuse clearance, platform integration, optional license, usage, customer expansion and downstream activation. These require independent product, legal and commercial decisions.

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]

02

Qualify before embedding

An interesting account is not an FDE engagement until the inputs and authority exist.

Named problem and sponsor

What specific adoption or transaction journey is blocked? Who owns the outcome and can decide?

Accessible boundary

Is there a real system owner, test environment, contract/API view and lawful data path?

Evidence-shaped success

Can both sides state acceptance tests, failure modes and an observable baseline?

Economic and reusable case

Is the effort funded or intentionally exploratory, with a bounded timebox and a learning that could recur?

Payments boundary

Who owns the payment instruction, funds, merchant order, risk decision and reconciliation? Which rail, data class, jurisdiction and network rules may apply?

Product and distribution fit

Could the work yield a rights-cleared reusable integration or channel opportunity? Mark both as hypotheses until demonstrated or contracted.

If any item is unknown, run discovery rather than calling the work an implementation. “No-go” and “not yet” are valid decisions.

[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]

Candidate dimensions, selected in the charter rather than universally required:

  • Agent identity and authentication: subject, provenance, credential lifecycle, revocation.
  • Delegated buyer authority: consent source, scope, expiry, human override.
  • Transaction authorization: who may issue payment instructions and who may bind funds or merchant orders.
  • Spend envelope and policy: limit, reservation/decrement, replay prevention, exceptions.
  • Payment interoperability: gateway/processor/rail interfaces, idempotency, settlement/status reconciliation.
  • Risk/fraud controls: decision point, escalation, false positive/negative assessment where relevant.
  • Audit evidence: version, actor, authority, event linkage, retention and dispute reconstruction.
  • Failure and recovery: denials, duplicate/stale requests, timeout, partial success, unknown outcome, rollback/compensation.
  • Operations: monitoring, incident route, on-call, runbook, maintenance owner and customer ability to operate the delivered scope.

[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]

Pre-engagement activity authorization

A gate decision is not an access grant. The FDE engagement lead maintains one versioned authorization record per proposed activity and transition in the approved evidence repository: opportunity/engagement ID; current and requested state; precise activity and excluded activity; parties and authorized customer counterpart; agreement or approved preliminary instrument identifier, version, signatories, execution/effective dates and permitted purpose; scope/SOW or expressly bounded discovery authority; named Decentra owner, staff and subcontractors with required consent; environment, systems, data classes, tool/AI path, credentials and access level; duration/expiry and revocation route; security/privacy/compliance and payment-instruction/funds authority decisions; funding/commercial approval; applicable conditional-control findings and open risks; linked evidence; named decision-makers and timestamp with timezone; advance/defer/decline/re-charter disposition. Record a negative decision and its blockers as carefully as an approval. No open-ended implied permission from a conversation, intake acceptance, unsigned draft, technical capability or prior engagement. Retain the instrument and customer authorization, not merely a summary.

State Allowed only within recorded boundary Forbidden boundary Minimum entry evidence and decision owner
1. Public/synthetic or expressly authorized pre-contract discovery Internal desk research using public information, Decentra-owned synthetic fixtures and non-customer systems; non-sensitive customer conversations and materials expressly authorized for that purpose. A customer may expressly authorize bounded non-sensitive preliminary discovery under a suitable approved instrument without a universal MSA prerequisite. No customer system access, confidential/sensitive customer data or secrets, customer-tenant testing, code changes to customer assets, committed build, payment instructions or live/production effects. Public information is not permission to use private APIs or identify a customer publicly. Opportunity, sponsor/contact and authorized discussion scope; provenance and synthetic-only classification (or express permission/instrument for otherwise non-public non-sensitive material), exclusions, timebox, named Decentra FDE lead and commercial owner, dated decision. Counsel/security review whether the actual material needs a preliminary instrument; customer authorized representative signs if a customer permission is needed. FDE lead and commercial owner approve internal discovery funding and scope.
2. Customer-approved limited-access discovery Read-only or otherwise narrowly specified access to a named nonproduction system/data enclave to map flows, APIs, controls and baseline; sensitive information only if expressly within a binding approved preliminary instrument or applicable agreement and separately approved access/data controls. Access may be narrower than the later implementation scope. No committed implementation, customer configuration mutation, unauthorized extraction/retention, unapproved external AI or subcontractor, payment instruction, live funds, production changes or access beyond purpose/expiry. Discovery authority never rolls forward into build. Executed applicable agreement or counsel-approved binding preliminary instrument granting the precise discovery and confidentiality/data rights; customer system/data owner written approval; environment/data/tool/access inventory, named roster including subcontractor consents, least-privilege and revocation, duration; counsel applicability decision, security/privacy approval and payment authority boundary (none unless specifically reviewed); commercial funding approval. Customer authorized system/data authority, Decentra FDE lead, counsel and security/privacy owners record dated decisions before access.
3. Authorized committed implementation Versioned design, code/config and tests solely for the signed, bounded journey in approved environments and with approved people/data/tools; nonproduction integration and authorized customer-witnessed acceptance preparation. No out-of-scope work, unapproved new data or AI/third-party path, assumed IP reuse, live payment/fund movement or production-effecting release. Test success and customer acceptance do not grant production authority. Effective executed agreement or approved binding instrument sufficient for implementation AND authorized scope/SOW (not an unsigned proposal); one journey, deliverables, acceptance/change route, term, named DRI/staff/subcontractors, environment/data/access and duration, security/compliance and regulated/network applicability, payment decision/funds authority map, commercial/payment terms and budget authority, risk owners and timestamped signoffs. Customer sponsor/system owner plus authorized contractual signatory, Decentra commercial/delivery signatory and required counsel/security reviewers approve their respective boundaries. If a preliminary instrument cannot legally cover committed build, obtain the required executed implementation terms first.
4. Production-impacting deployment Only the specifically authorized live change, access and effects, within an approved release window and rollback/monitoring/support arrangement; customer retains its named payment and change authority. No inference of permission from a charter, demo, acceptance, platform license, test credentials or previous release; no irreversible funds/payment effects outside expressly delegated authority. Do not claim general production certification. State 3 authority remains effective and expressly covers the live activity, plus separate customer release/change authorization for named system, data, rail and effects; environment-specific security testing/remediation, applicable legal/network/compliance decisions, payment/human approval controls, monitoring, incident route, reconciliation, pause/rollback, support owner and residual-risk disposition; named customer change/service/payment authority and Decentra technical, security, support, commercial and applicable counsel signers with timestamp and link.

Activity Authorization Policy · A0–A3

PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING. Existing states 1–4 remain the concise view; A0–A3 are activity classes, not lifecycle stages.

Activity-specific authority. Classify each proposed act at the highest applicable activity class before it begins. 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 sensitive access requires an effective applicable agreement or counsel-approved binding preliminary instrument granting those rights. 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 live release decision, not a consequence of A2 or acceptance. 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

Activity class Permitted actions Prohibited actions Prerequisites Required evidence Approval authority Expiration/review trigger Escalation path
A0 Preliminary discovery (existing state 1) Public desk research, Decentra-owned synthetic/non-customer-system exercises and general non-sensitive customer discussion within a recorded purpose/timebox; expressly permitted nonpublic non-sensitive material only within its permission and any instrument counsel determines necessary. Customer systems, tenants or secrets; confidential/sensitive data; customer-asset mutation or committed build; payment instructions/funds effects; production access/change; unapproved publicity. Opportunity and sponsor/contact, mission-fit and bounded question, provenance/classification, exclusions, named FDE/commercial owners, funding/timebox; express customer permission and counsel/security determination if material is not plainly public/synthetic. No universal MSA prerequisite for public/synthetic work. Opportunity ID, activity boundary, provenance/synthetic classification, permitted materials, funding and dated decision; any express permission and preliminary-instrument applicability finding. Decentra FDE lead and commercial owner for internal scope/funding; authorized customer representative for any customer-provided nonpublic material; counsel/security decide required protections. Timebox end, permission expiry/revocation or changed purpose/material/classification/personnel; review before any A1 act. STOP affected act; FDE lead to commercial owner and counsel/security, then customer authorized counterpart where customer permission is involved; record defer/decline or new authorization.
A1 Authorized customer discovery (existing state 2) Specifically approved least-privilege, read-only or otherwise narrowly defined discovery in named nonproduction systems/data enclaves; sensitive data only under expressly granted confidentiality/data/access rights. Committed implementation or configuration mutation; extraction, retention, external AI or subcontractor use outside permission; payment instruction/live funds, production change, access beyond purpose or expiry; automatic promotion to A2. Effective applicable agreement or counsel-approved binding preliminary instrument covering precise discovery and confidentiality/data rights; written customer system/data approval; named personnel and consented subcontractors; environment, systems, scope, data classification, tools, credentials/access level, security/privacy/compliance findings, retention/revocation and expiry; payment-authority boundary and funding decision. Instrument ID/version/signers/effective dates and clauses, customer approval, access roster/grants, system/data/tool inventory, classification, least-privilege/retention controls, risk and applicability decisions, dated approvals. Authorized customer system/data owner; Decentra FDE lead, counsel, security/privacy and commercial owner within their domains; contractual customer signatory where instrument requires. Permission or instrument expiry/revocation; roster, scope, data, tool, system, jurisdiction or access-level change; review before A2. STOP access/change, constrain or revoke credentials, preserve record; FDE lead to customer system/data authority and Decentra counsel/security/privacy and commercial owner; re-authorize before resumption.
A2 Authorized implementation (existing state 3) Versioned design, code/configuration, nonproduction integration and scoped tests/acceptance preparation for approved deliverables in approved environments with approved people, systems, data and tools. Out-of-scope build, unapproved AI/third-party/data path or IP reuse; live payment/fund effect or production release; treating tests/acceptance as live authorization. Executed applicable agreement or counsel-approved binding instrument effective for committed build, plus authorized scope/SOW and deliverables/acceptance/change route; named Decentra owner, customer counterpart, personnel and consented subcontractors; system/data/credential limits; security/privacy and applicable legal/network/compliance findings; payment/funds authority map and commercial/payment/budget approval; design, test, change and rollback controls. Executed instrument and approved scope/version, signers/dates, charter and deliverable criteria, roster and access grants, architecture/authority and data-flow map, risk/control dispositions, test/change/rollback plan, funding and timestamped decisions. Authorized customer contractual signatory and sponsor/system owner for their boundaries; Decentra delivery/commercial signatory and FDE technical lead; counsel, security/privacy and applicable payment/compliance reviewers retain their vetoes. Agreement/scope/access expiry or revocation; changed deliverable, person, subcontractor, system, data, tool, rail, payment effect, price/liability or material risk; review before A3. STOP changed work, secure access and evidence; FDE lead to customer sponsor/system owner, Decentra commercial/delivery, counsel/security and payment/compliance owners as applicable; re-charter through #g2 before resuming.
A3 Production-impacting activity (existing state 4) Only the versioned live change, access and payment effects expressly authorized for named environment, rail, window and people, under monitoring, incident, reconciliation, support, pause and rollback/recovery controls. Inferring live authority from A2, demo, test credentials, acceptance or license; unapproved irreversible payment/funds effects, scope expansion or general production-certification claim. A2 authority remains effective and covers live activity; scoped acceptance evidence and residual-risk disposition; separate written customer live/change approval with named production signer; environment-specific security/legal/network/compliance review; explicit payment-effect and human/funds decision authority (or explicit no-payment-effect boundary); change window, monitoring, incident/support owners, rollback/recovery and reconciliation plan. Acceptance dossier linked but distinct from release record; release ID/version, live scope/effects, customer approval and named production signer, payment authority, security findings/remediation, applicable risk signoffs, deployment/test/monitoring/incident/support/rollback/recovery and reconciliation evidence, dated go/no-go. Customer authorized change/service and payment authority for live effects; Decentra technical, security, support and commercial owners and counsel/compliance where applicable; each signs its own boundary. Release-window end, revocation or loss of effective A2 terms; change in version, system, rail, data, personnel, payment effect, control or residual risk; review for each new release. STOP/pause affected release or effect, invoke approved rollback/recovery and incident route; FDE lead and incident lead to customer change/payment/service authority plus Decentra security, support, counsel/compliance and commercial owners; fresh release approval before resumption.

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, tools/AI route, 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, customer approval and access/data/people controls are effective before customer or sensitive 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 AU-01/02/06/07/09 and applicable CB/CC findings), #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.

Transition rule: enter a state only after all listed evidence and the applicable Control Applicability Matrix findings are complete and effective. A narrower approved state remains valid only for its stated purpose and expiry; no automatic promotion. Before ANY committed implementation, sensitive access or production effect, verify documented required agreement or approved binding preliminary instrument, scope/SOW authorization appropriate to that activity, named owner/staff/subcontractors, environment/data/access scope and duration, security/compliance/payment authority and timestamped approvals. In particular, state 1 does not require a universal MSA for public/synthetic work, while state 2 sensitive access cannot rely on a casual pre-contract invitation; counsel confirms whether a preliminary instrument grants adequate rights and which additional paper is required. State 4 requires a separate release decision even after state 3 and customer acceptance.

On expired permission, changed personnel/subcontractor, data class, system, rail, AI tool, purpose, jurisdiction, price/liability, scope or production effect: pause the changed activity, revoke or constrain access as needed, preserve evidence and return to the relevant state/Charter review. Conflicting instruments, unknown signer authority or missing approval mean STOP the affected activity and escalate to FDE lead plus counsel/security and the customer's authorized system/data/payment authority as applicable; record disposition before resuming. Exceptions identify control, activity/environment/data, reason, mitigation, named customer and Decentra approvers, start/expiry, review and rollback. An exception cannot supply binding rights, cure missing required consent or retroactively authorize access, IP reuse or live funds. Do not impose a default staffing ratio, blanket contract form or arbitrary elapsed-time target.

03

Seven stages. One gate at a time.

Each stage has an owner, a tangible artifact and an exit decision. Open a stage to see its minimum bar.

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]

00Intake01Discover02Charter03Design04Deliver05Accept06Transfer
00Intake · decide whether to investigate

Produce

  • Account and sponsor, problem statement, candidate journey and known systems.
  • Reason to involve FDE rather than ordinary sales, product support or a generic SDK; confirm direct payments-mission fit.
  • Unknowns, immediate blockers and discovery timebox.
Exit: accept discovery, defer or decline. Partner owner and FDE lead record the decision and next owner. No engineering commitment is inferred from a meeting.

00 Intake — decide whether to investigate.

  • Produce: account and sponsor; payment-specific problem and candidate journey; known systems; why FDE rather than sales, support or an SDK; mission-fit decision; unknowns, claims status and discovery timebox.
  • Exit: customer/commercial owner and FDE lead record accept-discovery, defer or decline, next owner and permitted activity. No engineering, investor, license or customer commitment follows from a meeting. [v0.1 gate 00; Playbook Part I §1]

Authorization cross-check. An intake decision records only bounded discovery authority; it does not grant customer access. See the authorization-state record. Review the four activity states and applicability matrix.

Activity-class entry and stop conditions: A0–A3 Activity Authorization Matrix.

01Discover · map reality and baseline

Produce

  • Current journey, actors, trust boundaries, systems of record and integration surface.
  • Access and data inventory; legal/security and regulated/network questions; baseline pain and failure paths.
  • Initial Agentic Readiness status for only the capabilities relevant to this journey, with environment and evidence.
  • Options: configure existing feature, adapt primitive, build adapter, or do nothing.
Exit: one narrow opportunity is technically credible. Technical lead and partner system owner confirm facts versus assumptions; unknown critical permissions block charter approval.

01 Discover — map reality and baseline.

  • Produce: current journey, actors, trust/authorization and fund-flow boundaries, systems of record, interface and data/access inventory, regulatory/network issue list, baseline pain and failure paths; compare configure, adapt, build or do nothing; initial readiness dimension statuses and feasibility/capacity hypothesis.
  • Exit: FDE technical lead and customer system owner confirm facts versus assumptions and one narrow credible opportunity. Unknown critical permissions, custody or control placement block Charter approval. Discovery in a sensitive environment itself needs applicable pre-access approvals. [v0.1 gate 01; Playbook Parts I §§3–4]

Authorization cross-check. Before customer-approved limited or sensitive discovery, document the state-2 instrument, access/data/tool scope, people, expiry and customer/security/counsel approvals; otherwise use public or synthetic information only. Review the four activity states and applicability matrix.

Activity-class entry and stop conditions: A0–A3 Activity Authorization Matrix.

02Charter · authorize a bounded engagement

Produce

  • One journey, in/out-of-scope, parties, DRI, timebox, commercial basis and change route.
  • Acceptance tests including denial, replay, timeout, partial success and manual recovery.
  • Data/security obligations, customer-approved environment and tools, named personnel, test access path and stop conditions.
  • Applicable signed SOW and relationship terms; counsel decides whether a DPA, Security Addendum, AI Addendum or Payments Regulatory Flow-Down Schedule is required. Proposed documents are not assumed executed.
Exit: sponsor, delivery lead and required risk owners sign off. If price, staffing, access or liability is unresolved, label it explicitly and do not start committed implementation.

02 Charter — authorize bounded delivery.

  • Produce: one journey, in/out of scope, parties/DRIs and named staff, timebox, funding/commercial basis, applicable executed SOW and terms, change route; environment and data/tool/subprocessor approvals; applicable legal/security/network requirements and responsible signer; measurable acceptance including denial, replay, timeout, partial success, unknown outcome and manual recovery; relevant AI evaluation protocol and human decision boundary; customer support/training deliverables and stop conditions.
  • Exit: customer sponsor, Decentra delivery/commercial lead and required legal/security owners sign their respective decisions. No committed implementation or sensitive access without the contractual authority and access approvals applicable to the work. Unresolved pricing, staffing, IP, data, liability or regulatory dependency is explicitly blocked or scoped out, not assumed away. [v0.1 gate 02; Playbook Part I §5]

Authorization cross-check. Before committed implementation, document the state-3 effective governing instrument, authorized SOW or equivalent scope, named people/subcontractor consent, environment/data/access duration, security/compliance/payment authority and timestamped signers. Review the four activity states and applicability matrix.

Activity-class entry and stop conditions: A0–A3 Activity Authorization Matrix.

03Design · freeze interfaces and control placement

Produce

  • Sequence diagram, request/response and events, idempotency and reconciliation plan.
  • Authority model: identity, delegated intent, spend limits, custody, approvals and revocation.
  • ADR for bespoke versus potentially reusable code, with background/foreground provenance; test plan, telemetry and rollback.
  • Map human authorization, data flows (including prompts/logs), security tests and incident route before sensitive access or live effects.
Exit: reviewable design and no unresolved critical control gap. Partner technical owner signs the boundary; security/compliance approves relevant risk before sensitive access or live effects.

03 Design — freeze interface and control placement.

  • Produce: sequence diagram, request/response and event contracts, idempotency/reconciliation, authority/consent/spend/custody/approval/revocation map, human override, threat and data-flow model (including logs, prompts, model calls and backups), test/telemetry/rollback plan, rights-provenance ADR for bespoke versus potentially reusable work, operational failure owner.
  • Exit: customer technical owner approves its system boundary; FDE technical lead approves design; security/privacy and counsel/network reviewer approve applicable sensitive access, production effect and reuse questions. No unresolved critical control gap. This is not permission to reuse customer foreground work. [v0.1 gate 03; Playbook Parts I §§2–4]

Productization disposition. Open a candidate ID and provenance ADR for potentially reusable design; classify source, creators, dependencies and customer restrictions. Generalization is not reuse permission. Candidate procedure and register.

04Deliver · implement behind a controlled boundary

Produce

  • Versioned code/config, integration and security tests and traceable changes; synthetic data first, customer information only in its approved environment.
  • Record access roster, approved AI tools and potential reusable inventions as they arise; material scope or data changes return to Charter.
  • Observability for every irreversible action and a documented pause/rollback path.
  • Updated decision log whenever actual partner behavior differs from the design.
Exit: test environment demonstrates the scoped journey. A demo is not acceptance. Scope change goes back through charter and control review.

04 Deliver — implement behind a controlled boundary.

  • Produce: versioned code/config and dependency inventory, integration/security tests, traceable change records, synthetic data first, observed payment effects and status reconciliation, pause/rollback plan, staff/access ledger and weekly flags for reusable inventions; compare actual behavior with design and re-charter material deviations.
  • Exit: scoped journey demonstrable in its agreed test environment; technical lead records coverage, defects and limitations. A demo is not acceptance. New data classes, personnel, external AI tools, network access or live funds require the relevant reviews before use. [v0.1 gate 04; Playbook Part I §6]

Productization disposition. Quarantine customer-derived code, designs, tests and data from shared repositories and other engagements pending artifact-specific rights and security clearance; continue only authorized customer delivery. Candidate procedure and register.

Candidate identification or disposition is recorded under D1–D4 productization governance. Customer acceptance remains independent.

05Accept · prove behavior and recovery

Produce

  • Partner-witnessed tests: authorized, denied, expired, stale, duplicate, timeout and uncertain outcome.
  • Linked traces, payment/order status reconciliation, residual risks and incident exercise.
  • Explicit pass/fail against charter criteria and documented exceptions; use-case-specific AI metrics, datasets and human review only where relevant.
  • Record validated capabilities separately from the later production release decision and any platform license.
Exit: partner owner accepts the named scope, or it remains a pilot. Production change requires separate operational, security, legal and commercial approval where applicable.

05 Accept — prove behavior and recovery.

  • Produce: customer-witnessed authorized/denied/expired/stale/duplicate/timeout/uncertain-result tests as relevant, negative-security cases, linked traces, order/payment reconciliation, relevant AI accuracy/error metrics and datasets, incident exercise, residual risks and explicit pass/fail against the signed charter/SOW. Exceptions require named risk owner, mitigation and expiry.
  • Exit: customer acceptance owner accepts the named FDE scope, rejects it or leaves it a pilot with remediation. Production rollout is a separate operational, security, legal/network and commercial/change-control decision where applicable; do not infer it from acceptance. No platform license or merchant activation is inferred. [v0.1 gate 05; Playbook Parts I §§3,5]

Authorization cross-check. FDE acceptance does not authorize live effects: production-impacting deployment requires a separate state-4 release and payment-authority record. Review the four activity states and applicability matrix.

Activity-class entry and stop conditions: A0–A3 Activity Authorization Matrix.

Candidate identification or disposition is recorded under D1–D4 productization governance. Customer acceptance remains independent.

06Transfer · operate, learn, productize

Produce

  • Runbook, support owner, monitoring, incident route, version/maintenance obligations and SOW-scoped training so customer operators can run the agreed deliverable.
  • Reusable primitive candidate with invention log, contractual rights review, confidentiality screen, product owner, generalization test and known limits; keep restricted forks separate.
  • Retrospective: actual effort, partner outcome, failure patterns and next-company applicability.
Exit: operations accepts ownership and reusable learning is recorded. A partner fork stays labeled a fork until a product owner accepts it into the common core.

06 Transfer — operate, learn, productize.

  • Produce: runbook, monitoring and incident contacts, support/SLO obligations if contracted, credential/access disposition, version/maintenance and rollback ownership, champion training and handoff demonstration, customer operation signoff, residual risks, actual effort and outcome, rights-screened reusable-candidate log, platform feedback and future-company applicability.
  • Exit: customer operations and Decentra support owners acknowledge the precise ongoing obligations; customer can operate the contracted deliverables to the agreed degree. A partner fork remains a fork until legal clears reuse and product owner accepts maintenance into the common core. Self-sufficiency does not transfer Decentra background IP or imply free perpetual support. [v0.1 gate 06; Playbook Part I §§2–3, V (handoff and IP caveats)]

Productization disposition. Record one of four dated dispositions with owner/rationale. Core promotion requires counsel rights, confidentiality/security clearance, tests and product-owner maintenance signoff; customer acceptance and transfer do not wait for product review absent signed terms. Candidate procedure and register.

Candidate identification or disposition is recorded under D1–D4 productization governance. Customer acceptance remains independent.

04

Decision rights, not title theater

Name actual people per engagement. One DRI per decision; reviewers cannot silently substitute for an approver.

DecisionAccountable roleRequired input / record
Priority & sponsorPartner / commercial ownerPartner outcome, economic basis, internal priority and sponsor confirmation.
Engagement scopeFDE engagement leadCharter, staffing, timebox, acceptance, in/out-of-scope and change log.
Technical boundaryFDE technical lead + partner system ownerInterfaces, system of record, controls, observability and ADR.
Reusable productDecentra product ownerGeneralization criteria, maintenance owner, version policy and tests.
Security / privacyDesignated risk owner(s)Threat model, data inventory, access/custody review and exceptions.
Operational acceptancePartner service owner + Decentra support ownerRunbook, incident path, SLOs if agreed, on-call and handoff record.
Contract and IP rightsAuthorized signatory + counsel / IP ownerExecuted terms, scope, data and foreground allocation; artifact-specific reuse clearance.
Regulatory and network applicabilityCounsel + security + customer counterpartEntity, activity, data and network classification; approved obligations and distinct notice triggers.
Production and external claimsPartner release owner + Decentra risk / commercial ownersSeparate release evidence; verify any partner, patent, certification, license or revenue claim before use.

A small team may hold multiple roles, but the decision and its accountable signer remain explicit. Escalate disagreements to a named executive sponsor before widening scope or assuming risk.

[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]

Decision Accountable role / co-approval Evidence and veto boundary
Mission fit, priority, funding of discovery Executive sponsor for exception; commercial owner otherwise Payment outcome, economic basis, sponsor and capacity; executive cannot override security/legal gates. [EX-01, FI-01]
Engagement scope and change FDE engagement lead + customer sponsor under signed paper Charter, staffing, acceptance, scope/change record. [EX-02]
Interface, authority and payment effects FDE technical lead + customer system owner Sequence/ADR, system of record, control placement, test and rollback; no unilateral production authority.
Contract, foreground/background/residual rights Authorized signatory advised by legal/IP counsel Executed terms and artifact rights map; legal can block reuse/access where rights are absent. [LE-01, LE-02]
Data, privacy, security, personnel, external AI Designated security/privacy owner + customer approver where needed Data-flow, access roster, model/tool path, assessment, exception and revocation. [SE-01, SE-02]
Regulated/network applicability and notices Counsel + applicable customer/network owner; security incident lead for response Entity/activity/data classification, registration/validation evidence where required, separate clock matrix. [LE-03]
Reusable product admission Decentra product owner after legal/IP and security clearance Generalization criteria, clean provenance, tests, maintenance owner, version policy.
Production transition Customer change/service owner + Decentra technical/security/support and applicable legal/commercial signers Acceptance dossier, live-effect authorization, monitoring, support/rollback and contract scope. [EX-03]
Operational acceptance Customer service owner + Decentra support owner Runbook, training, SLO only if agreed, incident path and handoff record.
Public claim or partner naming Authorized communications/executive owner + counsel/customer consent as applicable Source-backed claims register; no inferred investor, network, IP or certification status. [EX-04]
05

Proposed field guardrails

If ratified, these apply before a company-specific overlay, subject to stricter legal and customer requirements.

Authority and data

Protect the boundary

  • Use least-privilege, revocable partner access. No shared production secrets in notes, repos or demos.
  • Define who may authorize what; an agent recommendation is not buyer consent or a payment instruction by itself.
  • Prefer synthetic data and sandbox rails; production data and live funds require explicit approval and control review. Customer information remains in customer-controlled or expressly approved environments; production-data approval is not permission to export it to Decentra systems, personal devices or external AI tools.
  • Record where credentials, payment tokens and personal data reside, transit and expire.
Delivery and claims

Protect the truth

  • Keep decision logs, test evidence and versioned artifacts tied to the scoped environment.
  • Do not conflate protocol compatibility, local demo, pilot, certified integration and production availability.
  • Do not announce partner, network, IP, compliance or commercial status without the owner’s supporting evidence and approval.
  • Stop and re-charter on unapproved irreversible effects, new data classes or material control changes.
  • Keep a named access roster; obtain internal and any contractual customer consent before other teams or subcontractors touch client work. Preserve evidence and report suspected incidents immediately to security and engagement leadership; a within-one-hour internal objective requires owner approval. External notice follows the applicable contract and counsel-reviewed rule, not a universal clock.
Exception rule. An exception names the violated control, risk, mitigation, approver, expiry and rollback. No “temporary” exception without a recorded owner and review date.

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. No contractor, advisor or other Decentra team may access client work without internal authorization and any required contractual/customer consent; flow down actual obligations before subcontractor access. 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.

PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Control Applicability Register · U/C/P

U-01–U-14 are intended universal field conduct upon owner ratification, not current approved policy. C-01–C-11 require an actual customer/activity/data/jurisdiction/contract determination. P-01–P-08 are OPEN negotiating positions, not customer commitments without approval and executed paper. Unknown means pending, not not-applicable. Record decisions at each affected gate and in the customer overlay.

Control ID Requirement/proposed position Classification Applicability trigger Required implementation evidence Responsible operational owner Required approval authority Source basis Current approval status Related lifecycle stage Related customer-overlay field
U-01 Name one accountable engagement owner and counterpart, decision rights, scope and stop owner; new explicit ownership row. Universal intended upon ratification Each opportunity, charter and changed ownership; no customer access implied. Opportunity/charter ID, named DRI and counterpart, decision log and replacement route. FDE engagement lead Executive/FDE practice owner for global adoption; commercial owner and customer sponsor for actual scope. source-index.html#roles, #g0, #g2; Phase 1 §2. PROPOSED — owner adoption pending #g0, #g2 1, 5, 10
U-02 Authorize each A0–A3 act separately; STOP affected act on missing, expired or conflicting rights and re-charter before resumption. Universal intended upon ratification Each proposed act, state transition, expiry or material change. Versioned activity record, effective instrument where required, allowed/excluded acts, signer/timezone timestamp, refusal and revocation. FDE engagement lead Decentra delivery/commercial and counsel/security in their domains; authorized customer system/data/change/payment authority for affected act. source-index.html#authorization-gate, #controls AU-01; activity-authorization-policy.md §§Activity-specific authority, STOP. PROPOSED — owner adoption pending #g0–#g5; A0–A3 1, 4, 5, 8, 11
U-03 Grant named, least-privilege, expiring and revocable access; keep production secrets out of shared notes, repos and demos. Universal intended upon ratification Any authorized access to customer assets. Access roster, grant/credential inventory, scope and expiry, revocation record. FDE technical lead Customer system/data owner and Decentra security. source-index.html#controls, #evidence AU-02; Phase 1 §2. PROPOSED — owner adoption pending #g1–#g4; A1–A3 4, 6, 11
U-04 Classify data; use synthetic fixtures first and customer-controlled or expressly approved enclave; no inferred export, retention or cross-context use. Universal intended upon ratification Any nonpublic customer material or proposed production-data use. Data-class/flow/storage/retention/deletion map and scoped permission. FDE lead and privacy owner Customer data owner, Decentra security/privacy; counsel for transfer rights. source-index.html#controls, #g4 AU-03; Phase 1 §4 L3 and §7 C4. PROPOSED — owner adoption pending #g1–#g4; A1–A3 4, 6, 11
U-05 Do not send customer data, prompts, logs, backups or outputs to external AI tools by inference from ordinary data access; separately approve tool, recipient, training and retention path. Universal intended upon ratification Any proposed AI/tool path involving customer material; otherwise record no-use boundary. Tool/model/recipient and data-flow inventory, no-training/retention decision, express permission or prohibition. Security/privacy owner Customer data/tool authority, Decentra security/privacy and counsel for applicable terms. source-index.html#controls, #g4 CB-02; Phase 1 §4 L3. PROPOSED — owner adoption pending #g1–#g4; A1–A3 4, 6, 11
U-06 Name personnel and subcontractors; authorize need-to-know access and remove access at exit; do not use informal helpers. Universal intended upon ratification Any customer work/access or roster change. Named roster, internal authorization, onboarding/vetting as determined, access/removal record; conditional consents under C-09. FDE engagement lead Decentra security/HR; customer access authority where required. source-index.html#controls, #roles AU-05; Phase 1 §4 L4. PROPOSED — owner adoption pending #g1–#g6; A1–A3 1, 4, 11
U-07 Immediately escalate suspected engagement incidents internally to security and FDE lead, preserve chronology and contain; no field-worker unilateral external notice. Universal intended upon ratification Suspected security incident affecting engagement. Incident route, timestamped discovery/escalation, preservation, containment and incident owner. Security incident lead and FDE lead Decentra security incident authority for response; counsel/customer authorities decide external notice under C-06. source-index.html#controls AU-06/CC-08; Phase 1 §4 L5. PROPOSED — owner adoption pending; one-hour staffed objective separately OPEN #g1–#g6 6, 10, 11
U-08 Preserve confidentiality and do not name/confirm a customer or make unverified partner, network or certification claims; operational need-to-know channels remain available. Universal intended upon ratification Any nonpublic engagement information or proposed external statement. Classification, access/claims record, source-backed wording and written consent where needed. FDE lead and communications owner Decentra communications/executive and counsel; customer authorized publicity authority where required. source-index.html#controls, #roles AU-03/AU-08/CC-06; Phase 1 §4 L7. PROPOSED — owner adoption pending #g0–#g6 1, 6, 10
U-09 Separate test from live change; require versioned release, customer live authorization, security tests, monitoring, reconciliation and pause/rollback. Universal intended upon ratification Any proposed production access, live effect or payment-impacting change. Scoped release decision distinct from acceptance, test/remediation, customer change/payment approval, monitoring/support and rollback. FDE technical lead Customer change/service/payment owner plus Decentra security, technical and support; counsel/compliance where applicable. source-index.html#authorization-gate, #g3–#g5 AU-07; Phase 1 §2 gate 05. PROPOSED — owner adoption pending #g3–#g5; A3 separately 3, 4, 6, 7, 12
U-10 Keep attributable versioned gate, exception, maturity and claims evidence; maintain separate customer-delivery and product/commercial ledgers. Universal intended upon ratification Every gate decision, exception or status assertion. Dated decision/evidence links, exception owner/expiry, scoped claim, independent delivery and product ledgers. FDE engagement lead Each gate owner; communications/counsel for external claims. source-index.html#mandate, #evidence AU-08; Phase 1 §§2,7. PROPOSED — owner adoption pending #g0–#g6 7, 8, 10, 12
U-11 Test positive and negative paths against bounded criteria; record customer-witnessed pass/fail and residual risks. Acceptance is not live release or platform adoption. Universal intended upon ratification Charter/test design and any FDE acceptance request. Signed-scope criteria, denial/replay/timeout/partial/uncertain-result traces, reconciliation, customer decision; SOW-specific metrics as agreed. FDE engagement lead Customer acceptance owner and Decentra delivery lead. source-index.html#g2, #g5, #evidence AU-09/CB-11; Phase 1 §2 gate 05. PROPOSED — owner adoption pending #g2, #g5 2, 7, 10, 12
U-12 Hand off agreed runbook, monitoring, incident/support and credential disposition so customer can operate contracted scope; no implied perpetual support. Universal intended upon ratification Transfer or cessation of authorized activity. Runbook, training/demonstration, support boundaries, owner acknowledgment, credential disposition. FDE/support lead Customer operations owner and Decentra support owner. source-index.html#g6, #evidence AU-10/CB-11; Phase 1 §2 gate 06. PROPOSED — owner adoption pending #g6 7, 9, 10
U-13 Log artifact creator, sources, dependencies and rights; quarantine customer-derived material from common core/other customers pending artifact-specific counsel and security clearance. Universal intended upon ratification Candidate artifact creation, invention or proposed reuse. Confidential candidate ID, provenance/ADR, rights and restriction map, segregation and counsel/security disposition. FDE technical lead IP counsel and security/privacy before movement; customer rights owner where terms require. source-index.html#g3, #productization-register AU-11; Phase 1 §§4 L2,5. PROPOSED — owner adoption pending #g3–#g6 9, 13
U-14 Keep FDE acceptance distinct from product admission, executed platform license, usage and merchant activation; promote only cleared tested core with maintenance owner. Universal intended upon ratification Any candidate for platform/core or commercial milestone assertion. Separate Lane A acceptance, rights/security/product decision, tests/version/maintenance and distinct executed-license/usage evidence if claimed. Product owner and FDE lead IP counsel and security/privacy for reuse; product owner for core; authorized signatories for commercial paper. source-index.html#mandate, #g6, #productization-register AU-12; Phase 1 §§1,7 C6. PROPOSED — owner adoption pending #g5, #g6 9, 10, 12, 13
C-01 Determine PCI DSS cardholder-data/service-provider responsibility; no blanket PCI certification. Conditional, counsel/customer determination Actual cardholder-data environment, scoped processing activity or customer/assessor/network contract obligation in the relevant jurisdiction/rail. Card-data and entity/role map, signed allocation, applicability decision and validation only if required. Security/compliance owner Counsel and customer PCI/data/network authority. source-index.html#control-applicability CB-04; Phase 1 §4 L6. OPEN — applicability undetermined #g1–#g3; before A1–A3 as relevant 4, 6, 11
C-02 Determine specific network service-provider status, registration/validation and rule flow-down; no universal registration. Conditional, counsel/customer determination Identified network/rail and provider role, actual activity/data or signed customer/network obligation in applicable jurisdiction. Role/rail/contract mapping, rule/version and required registration/validation evidence or reason not applicable. Payments compliance owner Counsel and customer network authority. source-index.html#control-applicability CB-05; Phase 1 §4 L6. OPEN — applicability undetermined #g1–#g3; A3 if live 3, 6, 11
C-03 Determine GLBA Safeguards or bank-interagency security duties/flow-downs separately. Conditional, counsel/customer determination Covered entity and protected information, bank/nonbank service activity, jurisdiction or signed bank/customer security clause. Entity/activity/data classification, applicable text and contract review, responsibility allocation. Privacy/compliance owner Counsel and customer bank/privacy authority. source-index.html#control-applicability CB-06; Phase 1 §4 L6. OPEN — applicability undetermined #g1–#g3 4, 6, 11
C-04 Determine bank examination, records, audit and supervisory third-party access obligations; guidance is not automatically a statute. Conditional, counsel/customer determination Regulated bank customer/service, examination scope, jurisdiction and actual law or signed audit/records clause. Service/entity map, clause/text review, access/retention boundaries and customer decision. Compliance owner Counsel and customer bank/examination authority. source-index.html#control-applicability CB-07; Phase 1 §4 L6. OPEN — applicability undetermined #g1–#g3, #g6 6, 10, 11
C-05 Determine Reg S-P or securities-recordkeeping/customer-information flow-down only for covered roles and activity. Conditional, counsel/customer determination Covered securities entity, information and service activity in relevant jurisdiction or signed customer flow-down. Regulated-role/information map, counsel primary-text review, executed flow-down if applicable. Privacy/compliance owner Counsel and customer regulated/compliance authority. source-index.html#control-applicability CB-08; Phase 1 §4 L6. OPEN — applicability undetermined #g1–#g3 4, 6, 11
C-06 Determine external incident recipient, threshold, authorized sender and each separate contract/network/regulatory clock; no universal external deadline. Conditional, counsel/customer determination Suspected event potentially meeting an actual customer contract, network rule or jurisdiction/entity-specific notice trigger. Signed terms/verified-rule trigger matrix, discovery chronology, counsel/customer determination and notice decision. Security incident lead Counsel and customer incident/regulatory authority. source-index.html#controls, #control-applicability CB-09; Phase 1 §4 L5 and §7 C7. OPEN — applicability undetermined #g1–#g6; incident response 6, 10, 11
C-07 Determine residency, cross-border transfer, DPA, retention and subprocessor locale constraints. Conditional, counsel/customer determination Actual protected data, recipient/transfer path and jurisdiction or executed customer locale/processing restriction. Data/role/region/recipient flow, terms and permitted retention/deletion decision. Privacy/security owner Counsel and customer data/privacy authority. source-index.html#control-applicability CB-01; Phase 1 §4 L3. OPEN — applicability undetermined #g1–#g4; before affected access 4, 6, 11
C-08 Determine customer-required vetting, background screening, onboarding and named-key-person replacement terms without presuming every employee needs consent. Conditional, counsel/customer determination Customer systems/data access, regulated customer role/jurisdiction or actual contract imposing vetting/replacement criteria. Contract/role finding, roster, screening/consent evidence within lawful handling and replacement approval if required. FDE lead and HR/security Counsel and customer authorized personnel/access authority. source-index.html#controls, #roles AU-05/CB-03; Phase 1 §4 L4. OPEN — applicability undetermined #g1–#g4; roster change 1, 4, 6, 11
C-09 Determine subcontractor consent, regulatory flow-down, due diligence and replacement before outsider access. Conditional, counsel/customer determination Named subcontractor/advisor proposed for actual customer activity/data/system, and applicable contract, regulated role or jurisdictional flow-down. Executed clause, subcontractor/recipient roster, due diligence, required written consent and flowed-down terms. FDE lead and procurement/HR Counsel and customer contract/access authority; security/privacy for data access. source-index.html#control-applicability CB-03; Phase 1 §4 L4. OPEN — applicability undetermined #g1–#g4; personnel change 1, 4, 6, 11
C-10 Determine human/institutional approval for regulated credit, fraud, dispute, SAR or funds decisions; agent recommendation alone never grants payment consent. Conditional, counsel/customer determination Actual journey delegates or affects a regulated decision/payment effect under applicable customer role, activity, rail or jurisdiction. Decision-rights/legal-role and authority map, human approval evidence, revocation/rollback. FDE technical lead Counsel and customer regulated/payment authority. source-index.html#qualify, #g3, #control-applicability CB-10; Phase 1 §4 L6. OPEN — applicability undetermined #g1–#g5; A3 before live effect 2, 3, 6, 11
C-11 Determine other network/acquirer/processor-specific operating, certification or sponsorship obligations not captured by C-02; no generic approval inferred. Conditional, counsel/customer determination Named acquirer/processor/network interface or rail, actual transaction/data activity, jurisdiction and applicable executed flow-down or rule. Counterparty/rail/role and rule/contract matrix, authorized owner decision, required certification/consent evidence if applicable. Payments compliance and FDE technical lead Counsel and customer acquirer/network/payment authority. source-index.html#qualify, #roles, #controls CB-05; Phase 1 §4 L6. OPEN — applicability undetermined #g1–#g3; A3 if live 3, 4, 6, 11
P-01 Negotiate background/foreground ownership, assignment, licenses and customer deliverable allocation; do not choose an unexecuted default. Proposed legal/commercial position Drafting or renegotiating customer IP/deliverable terms. Counsel-approved alternative, artifact rights schedule and executed clause before reliance. IP counsel and commercial lead Authorized Decentra and customer contractual signatories, advised by IP counsel. source-index.html#control-applicability CC-01; Phase 1 §4 L2 and §7 C5. OPEN — no customer commitment without approval and executed paper #g2, #g3 5, 13
P-02 Negotiate residual/general-application, license-back and derivative reuse rights distinctly from ownership; no memory or clean-room shortcut around confidentiality. Proposed legal/commercial position Proposed cross-customer rights or residual clause for a specific artifact. Clause/version, provenance/restrictions, customer permission and executed rights; security disposition before movement. IP counsel Authorized contractual signatories; IP counsel and security/privacy veto actual reuse, product owner admits core. source-index.html#productization-register, #control-applicability CC-01/CC-02; Phase 1 §§4 L2,5. OPEN — no customer commitment without approval and executed paper #g3–#g6 9, 13
P-03 Negotiate liability cap/base, exclusions and carve-outs rather than assert a universal damages classification. Proposed legal/commercial position Customer risk-allocation negotiation or changed price/liability. Counsel-reviewed alternatives, internal risk decision, signed deviation/terms. Counsel and commercial owner Decentra authorized risk/commercial signatory and customer contractual signatory. source-index.html#control-applicability CC-03; Phase 1 §4 L1. OPEN — no customer commitment without approval and executed paper #g2 5, 6, 10
P-04 Negotiate AI-output warranties, evaluation responsibility and IP/AI indemnity and loss allocation separately from general liability. Proposed legal/commercial position Proposed AI output, training/model use or warranty/indemnity clause in a customer offer. Counsel-reviewed AI terms and model/data path, scoped evaluations, approved indemnity and executed paper. Counsel and security/privacy owner Authorized customer/Decentra signatories and Decentra risk owner; security for tool path. source-index.html#controls, #control-applicability CC-02/CC-03; Phase 1 §§4 L1–L3. OPEN — no customer commitment without approval and executed paper #g2, #g5 5, 6, 7, 11
P-05 Choose modular agreement architecture and precedence: relationship agreement or equivalent, scoped SOW and only triggered DPA/security/AI/payments schedules; no universal MSA for public/synthetic A0. Proposed legal/commercial position Need for binding discovery, sensitive access, build or live customer obligations. Counsel applicability/precedence determination, approved instrument/version/signers and executed relevant terms. Counsel and FDE lead Authorized customer/Decentra signatories, security/privacy for applicable controls. source-index.html#authorization-gate, #controls CC-04; Phase 1 §4 L1. OPEN — no customer commitment without approval and executed paper #g0–#g2; A0–A3 5, 6, 11
P-06 Approve services price, exploratory subsidy, capacity and optional platform license/usage separately; modeled values are not operating targets or a customer order. Proposed legal/commercial position Any offer, funded exploration, license/usage proposal or budget exception. Approved budget/price and capacity, separate services/order terms and executed customer paper if offered. Commercial/finance owner Finance/executive commercial signatory and customer authorized signer for deal. source-index.html#mandate, #control-applicability CC-05; Phase 1 §§6–7 C6/C8. OPEN — no customer commitment without approval and executed paper #g0, #g2, #g6 5, 10, 12, 13
P-07 Negotiate publicity and customer naming/claim permissions; an internal source-backed claim is not external consent. Proposed legal/commercial position Requested customer quote, logo, partner/network status or public/investor communication. Bounded claim, source/version, written customer consent where needed and approved executed publicity clause/release. Communications/commercial owner Executive communications and counsel; customer publicity/signatory authority where required. source-index.html#controls, #control-applicability CC-06; Phase 1 §4 L7 and §7. OPEN — no customer commitment without approval and executed paper #g0–#g6 1, 6, 10
P-08 Negotiate acceptance, cure/change, termination/wind-down, data disposition and support limits; FDE acceptance cannot force platform purchase. Proposed legal/commercial position Drafting customer delivery, AI-evaluation, service or exit terms. Signed SOW criteria, adverse-path threshold, cure/termination and handoff/support schedule, approved change route. FDE/commercial lead Counsel and authorized customer/Decentra contractual signatories; customer acceptance/operations authority for performance. source-index.html#g2, #g5–#g6, #control-applicability CC-07/CB-11; Phase 1 §4 L1 and §2 gates 05–06. OPEN — no customer commitment without approval and executed paper #g2, #g5, #g6 5, 7, 9, 10

Legacy AU/CB/CC crosswalk

AU-01→U-02; AU-02→U-03; AU-03→U-04/U-08; AU-04→U-02/U-11 (buyer/payment authority remains a universal boundary, with regulated decisions C-10); AU-05→U-06; AU-06→U-07; AU-07→U-09; AU-08→U-08/U-10; AU-09→U-11; AU-10→U-12; AU-11→U-13; AU-12→U-14. U-01 makes ownership explicit; U-05 splits the universal no-inferred-AI-export boundary from legacy CB-02's engagement-specific terms. CB-01→C-07; CB-02→U-05 plus P-04 for negotiated AI terms (tool-specific determination retained in U-05 evidence); CB-03→C-08/C-09; CB-04→C-01; CB-05→C-02/C-11; CB-06→C-03; CB-07→C-04; CB-08→C-05; CB-09→C-06; CB-10→C-10; CB-11→U-11/U-12/P-08 (negotiated metrics/support remain SOW-specific, not universal thresholds). C-08 and C-11 expose separate customer-vetting and other acquirer/network determinations. CC-01→P-01/P-02; CC-02→P-02/P-04; CC-03→P-03/P-04; CC-04→P-05; CC-05→P-06; CC-06→P-07; CC-07→P-08; CC-08→U-07 only for immediate escalation. The legacy CC-08 one-hour internal objective remains a separate OPEN owner decision about staffing/coverage; it is not adopted here, a P customer clause or an external deadline. Preserve legacy anchors and ID aliases until all references are updated; no source row is silently ratified.

06

Minimum evidence pack

The handoff is a set of inspectable artifacts, not a retrospective claim of readiness.

ArtifactMinimum contentsWhen
Opportunity recordProblem, sponsor, candidate journey, qualification and no-go conditions.Intake
Discovery mapActors, flow, APIs, control boundaries, assumptions, baseline and options.Discovery
Engagement charterScope, acceptance tests, owners, timebox, commercials, environment and changes.Before build
Architecture / ADRInterface contracts, authority/custody, failure modes, integration placement and reuse choice.Before build
Risk & access recordThreat/data review, approvals, exceptions, credentials inventory and revocation.Before sensitive access
Acceptance dossierTest cases, linked traces, failures, recovery, partner decision and residual risks.Acceptance
Runbook & reuse noteOperational owners, alerts, incident path, known limits, maintenance and productization decision.Transfer
Contract & access matrixEffective signed terms, obligations, named team, approved tools, data flow and any regulatory/network applicability decision.Before build or sensitive access
Readiness & rights registerSelected capability/status/environment/evidence; IP provenance, invention flag and legal/security/product reuse disposition.Design through Transfer
Commercial evidence ledgerFDE acceptance apart from executed platform license, realized usage and measurable merchant activation; model outputs are not results.Acceptance and review

Metrics: time from intake to charter and to validated readiness; time to first reproducible test; acceptance pass/fail; approved production releases; recovery performance; handoff and customer self-sufficiency; escaped incidents and support load. Track rights-cleared reuse and reduced repeat effort separately from verified platform licensing, usage and merchant enablement. Set denominators and baselines before claims. Do not convert the draft financial model into targets.

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]

[F] Minimum evidence pack, versioned and access-controlled in an approved system of record:

  1. Opportunity and mission-fit record (00): sponsor, payment outcome, decision, no-go conditions.
  2. Discovery/readiness map (01): actors, authority, fund/data flow, systems, baseline, selected dimensions/status and options.
  3. Contract/charter matrix (02): effective SOW, applicable signed terms, staffing/consents, obligations, acceptance, fees, exclusions and change route.
  4. Architecture/ADR and rights map (03): controls, security and data paths, idempotency/reconciliation, IP provenance and review state.
  5. Risk/access/incident matrix (before sensitive access): threat model, personnel and credentials, exceptions, response owners and distinct external triggers if applicable.
  6. Build/release evidence (04): version, tests, security findings/remediation, change approval, monitoring and rollback.
  7. Acceptance dossier (05): scoped cases, traces, failures/recovery, relevant AI thresholds and datasets, customer signoff, residual risks and separate production decision.
  8. Handoff/reuse dossier (06): runbook, training, support/maintenance, customer operational signoff, rights-reviewed candidates and product disposition.
  9. Separate platform/commercial evidence: executed license or order, production usage/transaction telemetry, renewals and merchant enablement by actual count where measurable; never substitute a service acceptance record. [v0.1 §06; Playbook Part I §§2–6]

[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.

Keep candidate ID, provenance, D1–D4 decision or D3 deferral with follow-up owner/review trigger, rights/security/product evidence, and separate customer acceptance record. Candidate register.

PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Productization Candidate Register · D1–D4

Customer FDE acceptance and operational handoff do not wait for speculative platform admission. Keep candidate details and confidential evidence in an approved access-controlled system.

  1. Identify and segregate. At source-index.html#g1 Discover, log a potentially repeatable problem as a confidential observation, not an artifact cleared for reuse. At #g3 Design, open a unique candidate ID and provenance ADR for a potentially reusable design. During #g4 Deliver and #g5 Accept, the FDE technical lead flags new inventions, code, designs and tests as they arise, updates the candidate, creators, versions, dependencies and evidence, and compares actual implementation with the ADR. The engagement lead keeps customer-derived material in the approved customer boundary: no shared repository, other customer, demo, external AI/training, or publication while rights or security are unresolved. Record unknown/disputed background versus foreground ownership explicitly. A generalized interface, sanitized idea, residual-memory claim or proposed independent rewrite is not rights clearance. Authorized Lane A delivery and independently accepted FDE scope continue without waiting for a speculative Lane B product decision; material changes to data, personnel, tools, access or effect re-enter the activity authorization and Charter review.
  2. Review before movement. The engagement lead links the actual executed agreement, SOW/deliverable schedule, version, signers and effective scope, rather than relying on a standard-form assumption. IP counsel records artifact-specific background/foreground allocation, assignment, license-back, general-application/residual terms, confidentiality, derivative and third-party/open-source restrictions, permissible acts and contexts, and any required written customer rights approval. Security/privacy records data/secret leakage, classified content, fixture provenance, permitted environment, sanitization and applicable access/retention findings. Missing or ambiguous rights, consent or safety findings block cross-context movement; quarantine is a handling condition, not a disposition. A negotiated right or independently developed alternative still needs counsel's restriction review. Exceptions cannot create rights or waive law or consent.
  3. Decide at #g6 Transfer. In FDE–product triage, record a dated D1–D4 disposition or a documented D3 deferral, decision rationale, evidence, next action and named owner. The proposed product owner evaluates independently useful platform function, known limits, versioned implementation, reproducible positive/adverse/security tests, dependency inventory, release path, maintenance cost and support ownership. IP counsel controls rights; security/privacy controls safety; the authorized customer rights/data authority approves where actual terms require; the Decentra product owner alone accepts core scope and final maintenance. None substitutes for another's approval. Transfer also delivers the contracted runbook, credential disposition, support boundary and customer operations acknowledgment independently of product triage. If a decision is not yet possible, make D3 with prerequisite, follow-up owner and dated review trigger; never silently treat pending quarantine as a fifth final outcome. Reopen on changed terms, restriction, implementation, context, expiry or revoked permission with a dated superseding record and preserve history.
  4. Enforce the four dispositions:
  5. D1 Promote to core platform: only after documented artifact-specific reuse rights and required customer permission, confidentiality clearance, written legal/IP and security/privacy clearance, and product-owner acceptance of tests, version, limitations and maintenance owner. Move only the approved version through controlled repository/release review. Promotion does not authorize live production, customer naming, license/usage or second-context use.
  6. D2 Retain as customer-restricted: keep the controlled fork and evidence in the authorized customer environment with access, support and retention boundaries. No cross-customer copy of code, design, data, tests or derivative material without later artifact- and context-specific counsel/customer-rights and security clearance; record any reconsideration as a new dated decision.
  7. D3 Defer: keep the candidate quarantined; name the missing decision/evidence, follow-up action, owner and due date or objective review trigger. Review at that trigger; do not move the material while unresolved.
  8. D4 Reject: record the reason, no-replication instruction, evidence custodian and retention/disposal obligations under actual agreement, legal hold and security rules; document lawful deletion/return when due, rather than deleting required records by default.
  9. Verify reuse separately. Before any second-context copy or implementation, record that context's authorized rights, confidentiality/access and security determinations, approved artifact version and approvers. After use, link integration and test evidence, date, comparable effort baseline and observed effort, defects and support impact. Blank evidence means unverified, not zero. Lane A acceptance (#g5), A3 live release under activity-authorization-policy.md, Lane B admission, executed platform license, realized usage and publicity have separate decisions and ledgers. The six workstreams in source-index.html#boundary-matrix remain distinct: core platform, FDE integration, customer customization, reusable candidate, restricted deliverables and commercial/distribution; a candidate disposition does not collapse their boundaries.

Cross-references: source-index.html#productization-register, #g3–#g6, #evidence, #boundary-matrix, #authorization-gate; control-applicability-register.md U-10/U-13/U-14, C-07/C-09 when triggered, P-01/P-02/P-08 (legacy AU-08/AU-11/AU-12, CB-01/CB-03, CC-01/CC-02/CC-07). These controls and legal/commercial positions remain proposed/open, not ratified or executed permissions. baseline-inventory.md identifies the staged source as a private release candidate with owner approval pending; public accessibility, prior presence checks and proposed text do not establish approval.

Blank reusable candidate register

One row per candidate; duplicate the entirely blank row as needed. Populate only with permissioned references and dated decisions; leave unknown facts blank and keep their blocker visible in the evidence record. Decision value, once made, is exactly D1, D2, D3 or D4 as defined above; a D3 record must include follow-up owner and trigger. Keep dated superseded rows/decisions in restricted history. Separate status of quarantine from the decision field. An empty clearance or owner acceptance blocks D1; an empty second-context authorization blocks reuse.

Unique candidate ID Source engagement (confidential reference) Description Technical function Potential platform application Code/artifact references, version, creators and dependencies Background-versus-foreground IP classification and provenance Customer confidentiality, data class and permitted environment Actual contract/version, clauses and reuse rights/required customer consent Legal/IP review status and dated evidence Security/privacy review status and dated evidence Proposed product owner Final product and maintenance owner; acceptance evidence Decision (D1/D2/D3/D4) and date Decision rationale Supporting implementation/test evidence and limits Follow-up action Follow-up owner Review date/trigger Second-context reuse authorization (context, approvers, version, date) Second-context implementation/test and observed effort/defect/support evidence Retention/disposal obligations, custodian and evidence

Measurement without implied outcomes

For each permissioned cohort and fixed period, record numerator, denominator, evidence provenance, missing-data count and version. Disposition coverage = candidates with dated D1–D4 decisions / logged candidates; report D1/D2/D3/D4 counts and undecided quarantined candidates separately. D3 review timeliness = D3 candidates reviewed by their due date/trigger / D3 candidates whose trigger occurred. D1 clearance completeness = promoted candidates with linked rights/customer-consent-where-required, confidentiality, legal/IP, security and product-owner acceptance / all D1 candidates; unresolved or revoked permission stops movement. Verified second-context reuse = D1 candidates with separately authorized, tested second-context evidence / eligible D1 candidates; report mere promotions separately, and compare observed effort to a documented comparable baseline only where one exists. Report Lane A acceptance and handoff, separate A3 release approvals, executed license and realized usage from their own evidence ledgers, never infer them from candidate counts. No targets, customer outcomes or savings are claimed here. Suppress identifying or small-cell external aggregates unless confidentiality and publicity authority clear the exact claim.

07

How each company inherits the core

A company overlay records verified local facts and narrows the proposed global controls; it cannot delete a gate.

Company overlay / required fields

Use the blank Payroc field schema below as an anticipated first application; it asserts no customer facts. Keep the global standard linked and mark local facts, assumptions and approvals distinctly.

  1. Company, sponsor, owners and decision authority
  2. Specific business outcome and one first journey
  3. Current-state systems and system-of-record map
  4. Integration surfaces, credentials and data permissions
  5. Scope, exclusions, timebox and commercial status
  6. Partner-specific security, legal and operational constraints
  7. Acceptance evidence, failure tests and go/no-go decision
  8. Local exceptions with approver and expiry
  9. Runbook, support owner and reuse candidates
  10. Evidence links, open questions and next decision
  11. Regulated/payment-network role, jurisdiction, contract documents, approved data/AI environment and personnel roster
  12. Selected readiness dimensions and evidence; separate FDE, production and optional platform/commercial milestones
  13. Background/foreground rights, potential reuse clearance and downstream distribution assumptions

Inheritance rule. Global principles are the default; a company overlay may add constraints or request a documented exception, but cannot silently delete a global gate. Changes useful across multiple companies are proposed back to the global standard with an owner, evidence and version increment.

E / Blank Payroc overlay template

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

Field IDSeparately named fieldValueEvidence/approval
E-01Legal entity and contracting counterpartyTBD — requires customer confirmation
E-02Customer sponsor and authorized contractual signerTBD — requires customer confirmation
E-03Customer system, data, security, payment and operations authoritiesTBD — requires customer confirmation
E-04Decentra owners, backups and customer/Decentra delegation limitsTBD — requires customer confirmation
E-05Selected payment journey, outcome and exclusionsTBD — requires customer confirmation
E-06Payment actors, merchants and systems of recordTBD — requires customer confirmation
E-07Named systems, interfaces, API versions and railsTBD — requires customer confirmation
E-08Environment boundaries, test tenants and production systemsTBD — requires customer confirmation
E-09Data classes, flows, residency, retention and deletionTBD — requires customer confirmation
E-10Approved enclave, external AI/tool, log and backup pathsTBD — requires customer confirmation
E-11Agent identity, provenance and authenticationTBD — requires customer confirmation
E-12Delegated consent, scope, expiry and revocationTBD — requires customer confirmation
E-13Spend envelope, buyer limits and human approvalTBD — requires customer confirmation
E-14Payment/funds effects, custody and risk/regulated decision authorityTBD — requires customer confirmation
E-15Discovery instrument, version, signer, effective dates and A0/A1 scopeTBD — requires customer confirmation
E-16Implementation SOW, deliverables, price, change route and A2 scopeTBD — requires customer confirmation
E-17Staff/subcontractor roster, consent, credentials and access expiryTBD — requires customer confirmation
E-18Baseline and selected readiness dimensions by environmentTBD — requires customer confirmation
E-19Positive authorized-path tests and customer witnessTBD — requires customer confirmation
E-20Negative deny, expired, replay and duplicate testsTBD — requires customer confirmation
E-21Timeout, partial/uncertain result, reconciliation and recovery testsTBD — requires customer confirmation
E-22Acceptance criteria, pass/fail, residual risk and remediation ownerTBD — requires customer confirmation
E-23Separate A3 production release signer, rail, window and payment effectTBD — requires customer confirmation
E-24Production monitoring, pause, rollback and go/no-go evidenceTBD — requires customer confirmation
E-25Operations runbook, support/SLO boundary and customer handoffTBD — requires customer confirmation
E-26Internal incident route and contract-specific external notice determinationTBD — requires customer confirmation
E-27IP provenance, restrictions, candidate disposition and handoff rightsTBD — requires customer confirmation
E-28Services commercial milestone and funding statusTBD — requires customer confirmation
E-29Separate platform admission, signed license and metered usage milestonesTBD — requires customer confirmation
E-30Distribution/channel, merchant activation and claim/publicity authorityTBD — requires customer confirmation

Inheritance rule: customer-specific constraints may be stricter; a local overlay cannot silently waive a global gate. No Payroc implementation, contract, access, transaction flow, commitment or launch date is asserted here.

Every company overlay must record the actual U/C/P applicability decision, evidence, owner and signoff (or dated not-applicable rationale), linked to the applicable A-class and gate. Do not copy a conditional legal conclusion into the global mandate. Control register.

08

Adopt, review, revise

This is a proposed organization-wide standard, not evidence that every team has already approved or followed it.

To activate v1

Assign the stewards

Name an executive sponsor, FDE practice owner, product owner and security/compliance reviewer. Agree who can approve charters, risk exceptions and production transitions. Ratify the evidence pack and store it in an accessible system of record.

Operating cadence

Review the pattern, not just the deal

Review active engagement gates and blockers regularly; inspect acceptance and incidents at handoff; revisit the global standard after early partner learnings. Record a dated version and change rationale. Future company Foldys cite the version they inherit.

Source basis: v0.1 and the private Phase 1 source review of the FDE playbook, September funding report, 14-tab draft pro forma and available product context. The legal positions require counsel; the High-case model and pitch assertions are not approved targets or proof of partner commitments. Executive, legal, security and finance owners must approve their respective provisions before adoption. This proposal is not ratified; the prior live URL was publicly reachable and its approval/version history is unproved.

[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 private release candidate is prepared for Phase 3 adversarial review only; no public claim or deployment 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.

Policy status is separate from public accessibility

The four policy lifecycle statuses are Draft, Private Release Candidate, Approved and Superseded. This exact version remains Private Release Candidate — Owner Approval Pending, not effective policy. A read-only baseline fetch found the earlier frozen 150820-byte source-pre-rc2.html snapshot publicly accessible on Pages; it did not test this successor candidate. The working project metadata says unpublished; that metadata is not an access-control test. Neither fact proves who deployed them, authorization or ratification. Current accessibility must be rechecked for any current claim. Separate status-consistency artifact and proposed corrected language. GO-01 and EX-04 remain OPEN.

Post-upload read-only sample: public Pages root and same-name candidate path both returned HTTP 200, 150820 bytes, SHA-256 36914d8717617b003a743543900d32e7258bfdeb865e427ca06b9eb74055198a—the frozen predecessor, not this successor candidate. The public root matched its pre-upload fingerprint. This does not prove future isolation or publication permission; the private index was later updated to this candidate by explicit owner instruction, with the predecessor backed up as standard-pre-rc2-20261018-36914d871761.html; a subsequent sampled public Pages read still returned the predecessor bytes.

PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

v0.1-to-v1 Change Log

Provisional archived v0.1 comparison. Previous requirements are bounded paraphrases, not verified verbatim quotes. All changes OPEN.

Open separately identifiable review artifact · CSV

Change IDOriginal sectionRevised sectionPrevious requirement (bounded paraphrase, do not invent verbatim)New requirementReasonSource/decision basisApproval statusImpacted artifacts
CH-01v0.1 §01#mandateBounded embedded journey and smallest primitive; no full-stack promise.Payments-only FDE; separate independently accepted Lane A from optional Lane B platform commercialization and ledgers.Prevent scope/adoption inference.Archive §01; Phase 1 §§1–3; EX-01/02, FI-01OPEN — executive/FDE/finance, GO-014A A-01; 4D; 4F F-01/F-07
CH-02v0.1 §02#qualifySponsor, accessible boundary, baseline, economics and defer/decline.Payment journey/authority screen, per-environment readiness, capacity and bounded discovery.Measurable qualification.Archive §02; Phase 1 §§2–3; EX-01/02OPEN — owner/domain approval4A A-02; 4E; 4F F-02
CH-03v0.1 §03 gates 00–06#lifecycle, #g0–#g6Seven owner/artifact/exit gates and separate live decision.Retain all gates; make authorization, rights, adverse tests, separate release and customer-run transfer explicit.Executable gate exits.Archive §03; Phase 1 §2; EX-02/03OPEN — domain/customer gates4A A-03; 4E; 4F F-03
CH-04v0.1 §04#rolesNamed DRI and distinct customer/Decentra technical, product, risk and operations roles.Explicit contract/IP, network, incident, live and publicity signers/vetoes.Prevent review/approval substitution.Archive §04; Phase 1 §§2,4–5OPEN — owner and affected authorities4A A-04; 4C
CH-05v0.1 §05#controlsLeast privilege, synthetic preference, consent and expiring exceptions.Client enclave is not export/AI permission; roster, internal incidents versus external clocks, security tests and live release distinguished.Protect authority/data and avoid universalized notices.Archive §05; Phase 1 §4/§7 C4/C7; SE-04OPEN — counsel/security/customer4A A-05; control register; 4C
CH-06v0.1 §06#evidenceMinimum opportunity-to-handoff evidence pack.Versioned authority, rights, release and separate delivery/product/commercial proof with provenance.Do not substitute projections for results.Archive §06; Phase 1 §§2,6–7OPEN — evidence/domain owners4A A-06; 4G
CH-07v0.1 §07#inherit, #payroc-templateSeparate company overlay cannot delete gates.Expanded blank local fields for roles, paper, journey, data/AI, acceptance, live, support and IP.Localize only verified facts.Archive §07; staged #payroc-template; Phase 1 §2OPEN — customer/domain signers4E; 4C EX-02/03
CH-08v0.1 §08#adoptionProposed status, stewards, version/review cadence.Dated multidomain ratification, evidence repository, migration and independent publication gate.Prevent premature effectiveness.Archive §08; Phase 1 §§1,9; GO-01OPEN — owner/domain signers4A A-08; 4G
CH-09v0.1 §§02–03/05–06#authorization-gate, #g0–#g3, #evidenceNo unified state-transition authorization record.Four existing states aliased A0–A3; eight-field activity/permission/personnel/environment/duration/risk-commercial/evidence record; STOP and re-charter.Close Gap 1 without new gates.Baseline inventory Gap 1; activity-authorization-policy.md; LE-04OPEN — owner/counsel/customer authority4A A-02; 4C; 4E
CH-10v0.1 §05#control-applicability, #controlsGuardrails lacked per-control applicability classification.Preserve AU/CB/CC IDs via crosswalk to U/C/P view with trigger, boundary, evidence, DRI, veto and status.Separate field rules, conditional findings and negotiating positions.Baseline inventory Gap 2; control-applicability-register.mdOPEN — GO-01 and LE/SE domains4A A-05; 4C; 4E
CH-11v0.1 §§01/03/06#productization-register, #g3–#g6Reuse candidate note without disposition route.Quarantine, rights/security/product clearance and four dispositions D1–D4; separately authorized second-context use.Control cross-context movement.Baseline inventory Gap 3; productization-governance.md; LE-02/PR-01OPEN — counsel/security/product/customer if required4A A-07; 4D
CH-12v0.1 §§01–08#change-log–#claims-registerNo integrated A–G companion trace.Keep eight-section core and existing anchors; linked private A–G review package and claims/publicity gate.Inspectable decisions and source limits.Baseline inventory Gap 4; staged companions; Phase 1 §7OPEN — GO-01/EX-044A–4G
CH-13Staged #change-log, #approval-register, #open-decisions4B/4C/4F; proposed #evidence linksIntegrated tables have different column depths and overlapping decisions.Extract stable IDs with exact requested headers, source/decision links and explicit proposed/status/blocker fields; do not duplicate F decisions.Independently reviewable private CSV schemas and auditable joins.Baseline inventory lines 30–34; GO-01OPEN — governance owner; no extraction approval assumed4B, 4C, 4F; future private exports
CH-14Staged #boundary-matrix, #productization-register4D; proposed #boundary-matrix linksSix workstreams and four candidate dispositions exist but are not an eight-field workstream view.Keep six workstreams; record rights, act authorization, acceptance, reuse and commercial consequences separately; never map D1–D4 onto lanes.Correct route ambiguity without altering disposition meanings.baseline-corrections.md; productization-governance.md; LE-01/02/PR-01OPEN — IP/security/product/customer as applicable4D, candidate register; future private export
CH-15Staged #payroc-template, #claims-register4E/4GBlank overlay is grouped; claim rows have bounded language but not separate uniform proof/publicity columns.Split overlay into separately named unknown fields and claims into explicit class, proof and OPEN publicity columns, with no factual promotion.Enable field-by-field review without customer facts or false verification.Baseline inventory line 31; Phase 1 §7; EX-04OPEN — customer facts and claim release unresolved4E, 4G; future private exports
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Formal Approval Register

All 16 decisions OPEN. Proposed resolutions are not approvals or signatures.

Open separately identifiable review artifact · CSV

Decision IDDecision requiring approvalProposed resolution (explicitly proposed)Approval domainResponsible roleCurrent statusSupporting evidence requiredConsequence if unresolvedBlocking/nonblocking classification
EX-01Payment perimeter and edge exceptionsProposed: retain payments-only qualification; write narrow exception delegation.Strategy/policyExecutive sponsor, FDE practice ownerOPENWritten eligibility/exclusion and exception rule; #mandate/#qualify, F-01Cannot adopt perimeter/exception.Blocks global ratification; no implied engagement permission
EX-02Discovery/build delegation, economics and scopeProposed: fund/timebox A0; require separately effective A1/A2 instruments and authorized SOW as applicable.Commercial/engagementExecutive/commercial signatory, FDE lead, counsel for paperOPENDelegation, budget, effective terms, customer authority/scope; #g0–#g2, F-02/F-07No committed build or unbounded subsidy/change.Blocks affected sensitive access/build; not bounded public/synthetic A0
EX-03Live-effect decision rightsProposed: separate A3 per-release approval from acceptance.Production/paymentCustomer change/service/payment authority; Decentra technical/security/support, applicable counsel/commercialOPENVersion, rail/environment, payment authority, tests, monitoring, reconciliation, rollback/support; #g5–#g6, F-03No live effect.Blocks A3 release
EX-04External statements and namingProposed: claim-by-claim proof, consent and written release.PublicityExecutive communications, counsel, counterparty/customer where requiredOPENExact G claim/version/audience, primary proof, rights/consent, dated release; #claims-register, F-09No public partner/patent/certification/financing/performance claim.Blocks external claim/public derivative
EX-05Exception delegation and no-waiver setProposed: scoped mitigation, expiry and affected authority; never override rights/consent/law.Policy/riskExecutive sponsor, affected risk/legal/customer authorityOPENDefined form, domain veto, expiry, review; #controls, F-06No adopted exception mechanism.Blocks reliance on exception; not permission to bypass controls
LE-01Foreground/background/residual hierarchyProposed: counsel-reviewed alternatives resolved in signed terms.Legal/IPIP counsel, authorized executive signatoryOPENClause/version, actual artifact terms and authority; #boundary-matrix, F-04No default IP ownership or residual rule.Blocks reliance on default rights; global ratification dependency
LE-02Artifact-specific cross-context admissionProposed: quarantine until rights/customer consent if required, security and product acceptance.Legal/IP/productIP counsel, security/privacy, product owner, customer rights authority if neededOPENProvenance, actual contract/license/consent, security, tests/version/maintenance; #productization-register, F-04No cross-account copy/core admission.Blocks D1 movement/reuse, not independent Lane A acceptance
LE-03Conditional regulation/network and notice clocksProposed: primary-text and contract trigger matrix for actual role/rail/data/jurisdiction.Regulatory/legalRegulatory counsel, customer regulated/network authority, security incident leadOPENEntity/flow map, rule/version, signed flow-down, trigger/recipient/clock; #controls, F-05No universal PCI/network/bank/GLBA/Reg S-P or notice claim.Blocks affected determination/notice assertion and access/live activity requiring it
LE-04Binding phase-specific paper/precedenceProposed: select applicable agreement/equivalent, SOW and triggered schedules for A1/A2.Contract/legalCounsel, authorized customer/Decentra signatoriesOPENEffective instrument/version/signers, clauses/precedence, scope, schedules; #authorization-gate, F-02No sensitive access or committed build without adequate rights.Blocks A1/A2 as applicable; not universal A0 MSA
SE-01Data/enclave/AI routeProposed: classify data and separately approve each transfer/tool/retention path.Security/privacySecurity/privacy, customer data authority, counsel for transfersOPENData/AI/log/backup flow, enclave, retention, assessment and permission; #controls, F-05No unapproved client data or AI processing/export.Blocks affected access/process path
SE-02Roster, subcontractors, revocationProposed: named least-privilege roster and conditional consents/flow-downs.Security/personnelSecurity/HR, FDE lead, customer access authority as neededOPENRoster, vetting/consent where triggered, grants/expiry/revocation; #evidence, F-06No unauthorized person or subcontractor access.Blocks affected person's access
SE-03Live security readinessProposed: threat/adverse tests, disposition and rollback before separate release.Security/productionSecurity lead, customer change authorityOPENTest/remediation, monitoring/incident/reconciliation/rollback, residual-risk record; #g3–#g5, F-03No live transition.Blocks A3
SE-04Internal incident objective and coverageProposed: prompt internal escalation; separately decide whether a one-hour staffed objective can be adopted; do not make it an external notice clock.Security/operationsIncident commander, executive/FDE practice ownerOPENImmediate route, on-call roster/backups, exercise, coverage decision; #controls, F-06; external timing LE-03Cannot promise one-hour internal objective as ratified.Blocks that policy promise; incidents still require prompt escalation
FI-01Price/subsidy/margin/staffing/modelProposed: finance-approved budget, capacity and dated authoritative model before offers/targets.Finance/commercialFinance lead, executive/commercial ownerOPENContribution/capacity basis, actual cash/contracts, reconciled scope and metric definitions; #qualify, F-07No adopted prices, hiring or modeled targets.Blocks unapproved offer/target; not proof of actual revenue
PR-01Product admission and maintenanceProposed: specify candidate tests, release/version and named maintenance owner after legal/security vetoes.ProductProduct/engineering owner with IP/security reviewersOPENCandidate register, test/version/release/support criteria and dated decision; #g6, F-04/F-08No ratified global core admission or individual promotion.Blocks D1 until candidate clearance; not Lane A acceptance
GO-01Ratify exact v1 and distributionProposed: approve exact hash/version, stewards, domain dispositions, effective date and migration/access plan.GovernanceExecutive sponsor, FDE owner, counsel, security/privacy; finance/product domains as neededOPENApproved bytes/hash, signers/timestamps, evidence repository, migration/review; #adoption, F-01v1 remains private proposal; external derivative also needs EX-04.Blocks effective standard/publication inference
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Engineering and Commercial Boundary Matrix

D1–D4 are product dispositions, not the two business lanes. Rights and acceptance remain independent.

Open separately identifiable review artifact · CSV

CategoryPrimary objectiveResponsible functionOwnership/licensing considerationsAuthorization requirementsAcceptance responsibilityReuse restrictionsCommercial implications
Core platform (Lane B)Maintain independently useful versioned payment capabilities.Product/engineering owner, security, IP counselBackground/foreground and licenses evidenced per artifact; product controls maintenance, not customer rights.D1 only for eligible customer-derived candidate with executed rights, consent if required, counsel/security clearance and controlled release; A3 separate.Product owner accepts version, tests, limits and maintenance.No restricted foreground or cross-context use on inferred rights; second context separately authorized.License/order, usage and revenue need distinct signed/observed proof; platform existence is not a sale.
FDE integration (Lane A)Deliver one contracted payment journey and customer-run outcome.FDE lead with customer sponsor/system ownerSOW deliverables and actual rights determine allocation; Lane B rights not inferred.A0–A2 as applicable, signed scope/authority for build; A3 separately for live effect.Customer acceptance owner witnesses agreed positive/adverse criteria; Decentra delivery lead records dossier.No automatic platform promotion, cross-customer copy or external demo.Fees/subsidy approved separately; acceptance stands without platform purchase.
Customer customizationAdapt interfaces, configuration or fork inside authorized customer boundary.FDE technical lead, customer system ownerForeground assignment/license unresolved until actual agreement; distinguish third-party dependencies.Versioned scope, data/access permission, change route and customer system approval.Customer accepts contracted customization; FDE delivers evidence.Keep restricted pending per-artifact LE-02; no generalized-code shortcut.Bespoke price/support obligations in signed terms; no implied recurring license.
Reusable development candidateEvaluate a repeatable primitive without moving restricted material prematurely.FDE provenance owner, IP counsel, security/privacy, product ownerRecord creators, version, contract clauses, third-party rights and customer consent; D1/D2/D3/D4 only after decision.Candidate ID/ADR, quarantine, artifact-specific rights/security and product review; second-context authorization independent.Product owner for D1 tests/maintenance; customer acceptance remains separate.D2 stays restricted; D3 stays quarantined with trigger; D4 retention/disposal controlled; D1 scope-limited.No booked software value, channel right or measured savings merely from D1.
Customer-restricted deliverablesHand off protected contracted outputs and preserve obligations.Customer and Decentra custodians, contract/data ownersActual agreement controls ownership, confidentiality, retention and return/deletion.Approved enclave/roster, signed rights and applicable customer data directions.Customer accepts contracted deliverables and operations handoff where agreed.No shared repo, other account, external AI/training, demo or publication absent new clearance.Support/wind-down only as contracted; restriction is not platform revenue.
Commercial/distribution relationshipNegotiate services versus optional license, usage and channel rights distinctly.Commercial/finance, authorized customer channel/signatory ownerExecuted order/license/channel terms, territorial and publicity rights; IP rights remain artifact-specific.Approved budget/pricing, authorized signers and actual paper; claims need EX-04.Contracting parties accept deal obligations; finance validates realized metrics.Distribution does not clear restricted code/data or names by itself.Forecast/pilot/customer base is not ARR, merchant activation or realized usage.
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Consolidated Open Decisions Register

Nine deduplicated decision clusters. Due-before is a dependency, not an invented date.

Open separately identifiable review artifact · CSV

Decision IDOwner roleRequired decisionImpactNext actionBlocking dependency
F-01Executive sponsor and FDE practice ownerCanonical baseline/provenance, payments-only perimeter, exceptions, stewards and exact ratified version/distribution.Effective policy and representation.Obtain change/deployment history and written EX-01/GO-01 dispositions.Before global ratification; #mandate/#adoption, CL-01/02.
F-02Commercial signatory, FDE lead, counselPhase-specific discovery/build instruments, authorization/delegation, scope/change/stop and capacity.A1/A2 activity rights and bounded economics.Map actual signers, effective terms, A0–A2 acts and LE-04/EX-02 evidence.Before sensitive access or committed build; not universal public/synthetic A0 barrier.
F-03Customer change/payment/service authority; Decentra technical/security/support and applicable counsel/commercialSeparate live-effect signer, tests, rollback, reconciliation and operations.A3 production effect.Prepare per-release EX-03/SE-03 authority/test record.Before each live release, not upon #g5 acceptance.
F-04IP counsel, authorized signatory, security/privacy, product ownerOwnership/residual hierarchy and candidate D1–D4 disposition and maintenance criteria.Cross-context movement and core admission.Review actual clauses, provenance and third-party/customer consents; resolve LE-01/02/PR-01.Before reuse/promotion; global rule before ratification; #productization-register.
F-05Regulatory counsel, customer regulated/data/network authority, security/privacyActual role/rail/jurisdiction/data, DPA/AI/network applicability and each external notice clock.Access/live/notice and truthful regulatory claims.Build primary-text/contract trigger matrix under LE-03/SE-01.Before affected activity or external deadline assertion.
F-06Security/HR, incident commander, FDE practice ownerRoster/consent/revocation, immediate incident route, feasibility of proposed one-hour internal objective and no-waiver exceptions.Personnel access and operational promise.Evidence staffing/backups/exercise; resolve SE-02/04 and EX-05; keep external clocks in F-05.Before affected access and global one-hour promise.
F-07Finance and executive/commercial ownerExploratory subsidy, contribution/margin, capacity/hiring, price, accounting definitions and dated authoritative model.Offers and forecasts.Reconcile actual cash/contracts, budget and report/model/deck periods under FI-01/EX-02.Before commercial offer, staffing target or public forecast.
F-08Product/engineering, customer operations, Decentra supportProduct triage/tests/version owner versus SOW-specific handoff, training and support.Core maintenance and customer self-sufficiency.Document PR-01 admission and customer-run transfer separately.Before D1 core promotion or #g6 handoff respectively; not unrelated Lane A acceptance.
F-09Executive communications, counsel, finance/security/product and customer/counterparty rights ownerExact partner, patent, certification, financing, deployment, maturity and merchant claims and release permission.External/investor communication.Obtain primary G proof and consent, resolve EX-04/GO-01 and Phase 1 §7 contradictions.Before any external wording or public derivative.
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Evidence and Claims Register

CL-12 verifies only a bounded byte observation; no business outcome is independently established. All publicity decisions OPEN.

Open separately identifiable review artifact · CSV

Claim IDEvidence classBounded internal wording / source locatorExact proof needed for stronger claimPublicity status / authority
CL-01Documented; Requires verification of provenance/adoptionStaged source-index.html and provisional archived-v01.html each show eight core sections and seven gates; the canonical version and approvals are unresolved (#adoption, baseline inventory lines 3, 21–23). This is a directly inspectable artifact-structure fact, not business validation.Dated canonical archive/change history, exact approved hash and signed owner adoption/effective record.OPEN — executive/FDE owner and counsel; no effective-standard claim.
CL-02Documented observation; Requires verification of chronologyPhase 1 §1 recorded a different public snapshot from the archive; baseline inventory line 19 records a later observation whose bytes matched the frozen 150820-byte source-pre-rc2.html predecessor, not this successor candidate. Neither establishes deployer, permission, continuous current state or approval.Dated fresh capture, deployment audit/history and owner/publication authorization for the exact URL/version.OPEN — executive/FDE and communications.
CL-03Internally asserted; Requires verificationPlaybook and cited deck assert prospective or later launch-client, Visa participation and Payroc/Suede program/investor relationships (Phase 1 §7 C3; staged #claims-register). No counterpart relationship or deployment is established here.Dated executed counterpart agreements and scope, program work/acceptance evidence, investment receipts if claimed, naming consent and chronology.OPEN — executive communications, counsel, counterpart.
CL-04Strategic hypothesis; Requires verificationRights-cleared FDE integration may inform reusable platform capability or distribution, but Lane A acceptance does not confer Lane B, channel or merchant outcome (#mandate, Phase 1 §§1,5,7).Artifact-specific rights/security/product decision; separately authorized tested second context; signed channel/license and attributable observed activation.OPEN — product, commercial, counsel and counterpart rights owner.
CL-05Financial model assumption; Requires verificationFunding report historical/planned financing, draft High-case workbook and deck projections have different vintages/entities; modeled cash, revenue, hiring and routed volume are not receipts or targets (Phase 1 §§6–7 C1/C2/C8).Finance-approved dated model/assumptions, reconciled entity/period/accounting basis, executed financing and bank/cap-table receipts for actual cash, authorized forecast wording.OPEN — finance, executive and securities counsel.
CL-06Historical statement; Requires verificationFunding report describes June financing/partnership context, later deck/model asserts other plans or status; the events and transitions are not verified (Phase 1 §7 C1/C3).Contemporaneous signed documents, dated ledger/bank/cap-table and counterpart confirmations; source chronology and supersession record.OPEN — finance, executive, counsel and counterpart.
CL-07Internally asserted; Requires verificationDeck patent-filing and management IP-valuation references are not evidence of grant, ownership or independently valued assets (Phase 1 §7 C9; #source-boundary).Official application IDs, filing/status records, assignments/chain of title, counsel scope opinion; independent valuation method/report if value claimed and disclosure rights.OPEN — IP counsel and executive communications.
CL-08Internally asserted; Requires verificationNetwork/partner participation, service-provider registration, PCI/security certification and regulatory applicability are entity/rail/contract-specific, not established by a deck or playbook (Phase 1 §§4,7 C3/C7; LE-03).Exact entity/activity/rail/data/jurisdiction map, primary rule and signed flow-down, network/assessor/certifier record with scope and validity, counterpart consent.OPEN — regulatory counsel, security and executive communications.
CL-09Internally asserted; Requires verificationDesign, six-layer deck, repository README, sandbox/demo or pilot does not establish deployed full-stack production maturity or operated transactions (Phase 1 §7 C9; #qualify, #g5).Exact version/environment integration and security tests, customer acceptance, separate A3 live approval, observed transaction telemetry/reconciliation and operated support evidence for bounded claim.OPEN — product, security, customer release owner and communications.
CL-10Internally asserted legal/operational proposal; Requires verificationPlaybook clauses, client-enclave preference and example internal one-hour/other incident timings are not universal counsel-approved duties or executed customer terms (Phase 1 §4/§7 C4–C7; SE-04/LE-03).Counsel primary-text and actual contract applicability, adopted staffed internal coverage, customer permission and separate trigger/recipient/sender/external-clock matrix.OPEN — counsel, security incident owner and customer authority where applicable.
CL-11Requires verification; no actual commercial outcome establishedFDE acceptance, D1 promotion, A3 production release, executed license, metered usage, merchant activation and recognized revenue are different evidence states; no account-specific actual is supplied (#evidence, #boundary-matrix, Phase 1 §7 C2/C6).Signed acceptance and release/order records, rights-cleared product decision, metered usage and attributable activations, finance-recognized ledger with period/denominator, customer publicity permission.OPEN — finance, commercial, product and customer publicity authority.
CL-12Independently verified (technical byte observation only); Requires verification of provenanceAt the recorded baseline browser fetch, public Pages HTTP 200 returned 150820 bytes, SHA-256 36914d8717617b003a743543900d32e7258bfdeb865e427ca06b9eb74055198a, matching the frozen 150820-byte source-pre-rc2.html snapshot at 2026-10-18T18:39:35Z; no deployment actor, permission, continuing state or organizational approval follows.Dated deployment/change audit and owner publication authorization for the exact version; fresh fetch for any current-state claim.OPEN — executive/FDE owner, communications and counsel; no further external claim cleared.
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Verification and review readiness

Prior RC verification remains a historical project artifact; its public snapshot and old index link are not evidence for this candidate. This exact candidate is cross-checked against the requirements traceability matrix and its separate artifact files. The Doer execution and verification report records actual controller outcomes, substantive repairs, independent checks, and post-upload public-fingerprint status for Phase 3 handoff. Structural checks do not ratify policy, clear external claims or prove public isolation. Separate review pages: authorization matrix, control register, and productization register.

PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Requirements traceability and invariants

Trace six gap clusters, A0–A3, U/C/P, D1–D4 and all 14 invariants. INV-14 needs the parent public pre/post read-only check after any private upload. Separate review matrix · CSV.

Gap IDRequirement IDOperating standard sectionSupporting artifactLifecycle stageVerification methodEvidence locationCompletion statusOutstanding blocker
Gap 1 — activity authorityG1v1-private-release-candidate-20261018.html#authorization-gate, #activity-authorization-matrixactivity-authorization-matrix.csv; change-log.csv CH-09A0–A3; gates 00–06Compare four activity rows, eight headers, stop/re-charter and phase-specific instrument/effect boundaries against integrated textCSV rows A0–A3; candidate lines 15–114PASS (structural); OPEN (actual authorizations)EX-02, EX-03, LE-04 and customer/domain signers; no opportunity-specific instrument or permission supplied
Gap 2 — applicabilityG2v1-private-release-candidate-20261018.html#control-applicability, #controlscontrol-applicability-register.csv; change-log.csv CH-10Gates 00–06; before affected actParse 33 unique U/C/P rows with classification, trigger, evidence, owner, approval and status; compare legacy crosswalkCSV U-01–U-14, C-01–C-11, P-01–P-08; candidate lines 191–638PASS (structural); OPEN (ratification/applicability/terms)GO-01, LE-03, SE-01 and actual role/rail/data/contract determinations
Gap 3 — reuse dispositionG3v1-private-release-candidate-20261018.html#productization-register, #g3–#g6productization-candidate-register.csv; boundary-matrix.csv; change-log.csv CH-11/CH-14Design–Transfer; separately authorized second contextInspect four distinct dispositions, quarantine and 22-column blank candidate record; ensure six workstreams do not become disposition codesCandidate lines 642–707; blank candidate CSV row 2; boundary CSV six data rowsPASS (procedure/schema); OPEN (any actual disposition)LE-01/02, PR-01, artifact rights/customer consent, security and product acceptance; no candidate populated
Gap 4 — integrated review packageG4v1-private-release-candidate-20261018.html#change-log, #approval-register, #boundary-matrix, #payroc-template, #open-decisions, #claims-registerchange-log.csv; approval-register.csv; boundary-matrix.csv; payroc-overlay-template-rc2.csv; open-decisions.csv; evidence-claims-register.csv; CH-12–CH-15Cross-gateParse CSV schemas/IDs; resolve six local HTML anchors; check open decision and claim statusesCandidate named anchors; CH-01–CH-15, EX/LE/SE/FI/PR/GO rows, F-01–F-09, CL-01–CL-12PASS (local tables/anchors); OPEN (decisions/claims)All 16 approval rows remain OPEN. Verify package-relative links and table equality against the complete candidate and review artifacts; historical frozen-source root-absolute URLs are outside the new package link scope. See the cross-artifact verification report.
Gap 5 — publication consistencyG5v1-private-release-candidate-20261018.html#adoption, #publication-status, #source-boundarypublication-status-consistency.html; baseline-manifest.json; source-pre-rc2.html; evidence-claims-register.csv CL-02/CL-12Adoption/publication independent of gatesCompare intended governance label with recorded read-only baseline byte observation; do not infer current access or deployment actorFrozen source-pre-rc2.html snapshot and baseline-manifest.json public_observation; successor index.html#publication-status and #source-boundary explicitly distinguish the later candidate.PASS (frozen-baseline/successor distinction in candidate); OPEN (publication authorization); UNKNOWN (successor live public access)GO-01/EX-04, authorized owner/hosting deployment audit and fresh public read-only fingerprint. Recorded baseline matched frozen source only; successor has not been tested publicly.
Gap 6 — trace and independent verificationG6v1-private-release-candidate-20261018.html#verification-record, #adoptionThis matrix; all listed local inputs; baseline-manifest.jsonAll seven gates / reviewProgrammatic CSV row/width/status and HTML ID/gate/fragment checks reported below; trace each numbered invariantVerification report below; candidate #verification-record; manifest staged and public observationsPASS (this local trace/report only); OPEN (substantive adoption)Presence-only Doer verifier is insufficient; human review and parent public pre/post check remain
Gap 1 — activity authorityA0#activity-authorization-matrix, #g0–#g1activity-authorization-matrix.csv A0 rowPreliminary discovery; not gate 00 itselfConfirm public/synthetic timeboxed activity and no universal MSA; nonpublic material needs permission and counsel/security determinationCSV row 2; candidate lines 68–76PASS (structural); OPEN (any nonpublic act)Sponsor, scope/funding and material provenance/permission if applicable
Gap 1 — activity authorityA1#activity-authorization-matrix, #g1activity-authorization-matrix.csv A1 rowCustomer discovery before affected accessConfirm effective applicable instrument and written customer system/data approval, named roster and expiryCSV row 3; candidate lines 78–86PASS (structural); OPEN (actual access)LE-04, SE-01/02, customer system/data owner, counsel/security
Gap 1 — activity authorityA2#activity-authorization-matrix, #g2–#g5activity-authorization-matrix.csv A2 rowCommitted implementationConfirm binding build authority, approved scope/SOW, people, data, risk/payment and funding; tests do not grant live effectCSV row 4; candidate lines 88–96PASS (structural); OPEN (actual build)EX-02, LE-04, signed scope and customer/Decentra domain decisions
Gap 1 — activity authorityA3#activity-authorization-matrix, #g5–#g6activity-authorization-matrix.csv A3 row; approval-register.csv EX-03/SE-03Separate per-release production actConfirm release ID/version, written customer live signer, payment authority, window, monitoring/reconciliation and rollback separate from acceptanceCSV row 5; candidate lines 98–105, 121PASS (structural); OPEN (actual release)EX-03/SE-03 and separate customer live/change/payment authority
Gap 2 — applicabilityU-01–U-14#control-applicability, #controlscontrol-applicability-register.csvCross-gate; triggers per rowVerify contiguous exact IDs and classification/status; these are intended universal conduct only upon ratificationCSV rows 2–15; candidate line 191 and legacy crosswalk line 638PASS (14 rows/IDs structurally); OPEN (owner adoption)GO-01; U-07's one-hour staffed objective separately OPEN under SE-04
Gap 2 — applicabilityC-01–C-11#control-applicabilitycontrol-applicability-register.csvBefore triggered access, activity, live effect or noticeVerify contiguous exact IDs, conditional classification and actual trigger/authority; no blanket PCI/network/GLBA/bank/Reg S-P/notice conclusionCSV rows 16–26; candidate line 191PASS (11 rows/IDs structurally); OPEN (applicability)LE-03, actual entity/role/rail/jurisdiction/data/contracts and customer/counsel findings
Gap 2 — applicabilityP-01–P-08#control-applicabilitycontrol-applicability-register.csvNegotiation/contracting, not automatic gate permissionVerify contiguous IDs and OPEN proposed legal/commercial classification, not signed termsCSV rows 27–34; candidate lines 191, 638PASS (8 rows/IDs structurally); OPEN (execution)Counsel, commercial/customer authorized signers and executed paper; not ratified customer commitments
Gap 3 — reuse dispositionD1#productization-register, #g6productization-candidate-register.csv; boundary-matrix.csv core platformTransfer/product decision; A3 and second context separateInspect clearance/consent/security/product tests/version/maintenance requirement; blank register prevents actual promotion claimCandidate line 647; blank CSV decision column row 2PASS (rule); OPEN (actual D1)LE-02/PR-01 and artifact-specific rights/customer permission, security/product signoffs
Gap 3 — reuse dispositionD2#productization-register, #g6productization-candidate-register.csv; boundary-matrix.csv restricted deliverablesTransfer/restricted retentionCheck customer-restricted fork, no cross-account copy without fresh clearanceCandidate line 648; blank CSV decision column row 2PASS (rule); OPEN (actual D2)Actual contract/customer restrictions and named custodian/retention evidence
Gap 3 — reuse dispositionD3#productization-register, #g6productization-candidate-register.csvDeferral/review triggerCheck quarantine plus follow-up action, owner and date/trigger; blank row is not a recorded D3Candidate lines 645, 649; CSV follow-up/trigger columns, row 2 blankPASS (rule); OPEN (actual D3)Missing candidate evidence/owner/review decision
Gap 3 — reuse dispositionD4#productization-register, #g6productization-candidate-register.csvRejection/disposalCheck reason, no-replication, custodian and contract/legal-hold retention before deletionCandidate line 650; CSV retention/disposal column row 2 blankPASS (rule); OPEN (actual D4)Actual disposition and lawful retention/deletion direction
Gap 4 — integrated review packageINV-01 — exactly seven stages#lifecycle, #g0–#g6change-log.csv CH-0300–06Extract details.gate IDs, numbers and summary names, compare exact ordered setCandidate lines 115–122: g0/00 Intake; g1/01 Discover; g2/02 Charter; g3/03 Design; g4/04 Deliver; g5/05 Accept; g6/06 TransferPASS (structural)Gate exit decisions for real engagements unprovided
Gap 1 — activity authorityINV-02 — release distinct from acceptance#g5, #activity-authorization-matrixA3 CSV; open-decisions.csv F-03Accept then separately A3Inspect separate acceptance dossier/release record and signerCandidate lines 101–102, 111, 121; A3 CSV row 5PASS (structural); OPEN (release)EX-03/SE-03, customer live/change/payment approval
Gap 2 — applicabilityINV-03 — U versus C#control-applicabilityControl CSV U/C rowsAny triggered activityCompare classification/status and applicability trigger; do not globalize conditional dutiesCSV U-01–U-14 rows 2–15 versus C-01–C-11 rows 16–26; candidate line 191PASS (structural); OPEN (ratification and actual C findings)GO-01 and LE-03/customer-specific determinations
Gap 2 — applicabilityINV-04 — P not signed#control-applicabilityControl CSV P rows; approval-register.csvNegotiationCheck P classification/status and executed-paper conditionCSV P-01–P-08 rows 27–34; candidate line 191PASS (structural); OPEN (contracts)Counsel and authorized customer/Decentra signers
Gap 3 — reuse dispositionINV-05 — foreground not presumed owned#productization-register, #g3Control CSV P-01; approval-register.csv LE-01Design–TransferCheck unknown/disputed allocation requires actual clause review; no default ownershipCandidate lines 643–644; P-01 CSV row 27; LE-01 approval rowPASS (structural); OPEN (rights)LE-01 and actual artifact/contract allocation
Gap 3 — reuse dispositionINV-06 — reuse rights clearance#productization-registerControl CSV U-13/P-02; approval LE-02Before movement/second contextCheck quarantine, counsel/security/customer consent where required, distinct second-context permissionCandidate lines 644, 647, 651; U-13/P-02 CSV rowsPASS (structural); OPEN (clearance)LE-02/PR-01, actual rights and security findings
Gap 1 — activity authorityINV-07 — approved data handling#controls, #activity-authorization-matrixControl CSV U-04/U-05/C-07; overlay E-09/E-10Before data/tool pathCheck classification, approved enclave, external AI/retention/export not inferredCandidate lines 81, 109–110, 185–190; overlay CSV E-09/E-10 TBDPASS (structural); OPEN (specific path)SE-01, customer data/tool authority, counsel where transfers apply
Gap 1 — activity authorityINV-08 — personnel#activity-authorization-matrix, #rolesControl CSV U-06/C-08/C-09; overlay E-17Before access/roster changeCheck named roster, least-privilege, conditional vetting/subcontractor consent and removalA1/A2 CSV rows 3–4; U-06/C-08/C-09 control rows; E-17 TBDPASS (structural); OPEN (actual roster)SE-02, HR/security and customer consent if triggered
Gap 2 — applicabilityINV-09 — internal vs external incident#activity-authorization-matrix, #controlsControl CSV U-07/C-06; approval SE-04/LE-03Incident across gatesCheck prompt internal escalation distinct from contract/network/regulatory external recipient/clock; one-hour internal objective not adoptedCandidate line 112; U-07/C-06 rows; approval SE-04PASS (structural); OPEN (staffing/external clocks)SE-04 coverage decision; LE-03 actual contract/primary-text triggers
Gap 3 — reuse dispositionINV-10 — Lane A is not Lane B#mandate, #productization-register, #boundary-matrixBoundary CSV Lane A/Lane B rows; claims CL-04/CL-11Accept/Transfer then optional productCompare independent delivery and product/commercial ledgers and non-inferenceCandidate lines 9–11, 651; boundary CSV rows 2–3PASS (structural); OPEN (actual outcomes)Rights/product admission and separately executed license/usage/activation evidence
Gap 4 — integrated review packageINV-11 — financial model not actual#mandate, #evidence, #source-boundaryClaim CSV CL-05/CL-06; approval FI-01; open F-07Qualification/offer/claimsCheck model labeled hypothesis and no revenue/funding assertion from workbookCandidate lines 12, 641, 714; CL-05/06 rowsPASS (structural); OPEN (finance proof)Dated authoritative model, cash/contracts/ledger reconciliation and authorized claims
Gap 4 — integrated review packageINV-12 — Payroc fields not global facts#inherit, #payroc-templatepayroc-overlay-template-rc2.csvOverlay by actual customer gateCheck E-01–E-30 all TBD and approval cells blank, no Payroc implementation assertedCSV rows 2–31; candidate lines 707–708PASS (blank schema); UNKNOWN (customer facts)Customer confirmation, permissions, signed paper and E-field evidence
Gap 4 — integrated review packageINV-13 — all OPEN approvals owned#approval-register, #adoptionapproval-register.csv; open-decisions.csvRatification and affected gatesParse all decision IDs/current status/responsible role, not just count OPEN labelsApproval CSV rows 2–17: EX-01–05, LE-01–04, SE-01–04, FI-01, PR-01, GO-01; each Responsible role nonblank and OPENPASS (16 owned OPEN rows); OPEN (decisions)Each named role's evidence/decision; GO-01 cannot be supplied by this matrix
Gap 5 — publication consistencyINV-14 — public artifact unchanged#publication-status, #adoptionbaseline-manifest.json; publication-status-consistency.htmlAfter any private upload; parent-only public checkRead-only public pre/post sibling and post-index root byte/hash comparison; private index and backup readback; no Pages writepublic-preupload.json; public-postupload.json; public-post-index.json; standard-pre-rc2-20261018-36914d871761.html hosted backup; private raw/index readbackPASS — sampled public root unchanged at initial sibling upload and subsequent owner-directed private index update (HTTP 200, 150820 bytes, SHA-256 36914d8717617b003a743543900d32e7258bfdeb865e427ca06b9eb74055198a); same-name public path served predecessor fallback, not successorFuture isolation, prior deployment provenance and publication permission remain UNKNOWN/OPEN; this sampled comparison is not an authorization or a continuous-access guarantee
DECENTRA FDE OPERATING STANDARD v1 — PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING

Source trail and evidence limits

Playbook legal positions require counsel and engagement-specific contracts; regulatory claims and deck assertions are not independently verified. Six repository READMEs describe sandbox/local work, not blanket certification or production. Broker-dealer work is outside this global FDE mandate. No Payroc implementation plan is supplied.