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.

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]

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.

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.

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.

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.

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.

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.

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.

DECENTRA FDE OPERATING STANDARD v1 — PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING

Control Applicability Matrix

Download 31-row control matrix CSV · Private project file; classification and approval status remain controlling.

(proposed)

Category A = intended universal field conduct if ratified, not presently effective policy. Category B = obligation/control applied only on its specific trigger after counsel and the customer's applicable authority classify it; a listed regime is a question, not an assertion that Decentra or every customer is subject to it. Category C = unresolved proposed legal/commercial position; status OPEN, with no contract effect until approved and embodied in applicable signed paper. Matrix owners prepare evidence; approval authorities retain veto over their subject. Each row is checked at entry and at material scope change. A—pending means proposed pending global ratification and engagement-specific permissions; B—open means applicability not determined for any particular engagement here; OPEN means an unresolved negotiating/owner choice. Source links are locations in the staged index, supplemented by Phase 1 §4 (L1–L7) and §7 (C4–C7); playbook assertions require counsel review.

Control ID Description Category A universal / B conditional / C proposed legal-commercial Applicability trigger Required evidence Responsible owner Approval authority Source/rationale Current approval status
AU-01 State, owner and scope of activity authorization; stop on missing/conflicting consent A Each intake/transition/change Versioned state record, permissions, effective instrument if needed, dated decision FDE lead Customer authority for customer activity; Decentra commercial/delivery and counsel/security for their domains #qualify, #g0–#g2, #controls; no meeting grants access A—pending
AU-02 Least-privilege, expiring/revocable named access; no shared production secrets A Any access to customer assets Roster, least-privilege grant, credential inventory, revocation FDE technical lead Customer system owner and Decentra security #controls, #evidence, SE-02 A—pending
AU-03 Confidentiality, synthetic-first and customer-controlled or expressly approved data enclave; no inferred export A Any nonpublic customer material Classification, data-flow/storage/retention map, permission, deletion route FDE lead and privacy owner Customer data owner, security/privacy and counsel for transfers #controls, #g4, SE-01 A—pending
AU-04 Agent proposal distinct from buyer consent/payment authority; map human/institutional decisions A Any agentic payment journey Actor/authority, revocation, funds/custody and system-of-record map FDE technical lead Customer payment/system authority and Decentra security #mandate, #g3, #controls A—pending
AU-05 Named staff and controlled access; no informal helper or subcontractor access A Any customer work/access Roster, internal approval, removal record FDE lead Decentra security/HR and customer if required #controls, #roles, SE-02 A—pending
AU-06 Prompt internal suspected-incident escalation and preservation; no unilateral external notice A Suspected engagement incident Incident route, event chronology, preservation/containment and owner Security incident lead and FDE lead Decentra security incident authority; counsel for notices #controls, SE-04; distinct from external clocks A—pending
AU-07 Separate controlled production change, testing, monitoring and rollback A Proposed live effect Versioned release, tests, customer change approval, rollback and reconciliation FDE technical lead Customer release/payment owner plus Decentra security/support and applicable legal #g3–#g5, #controls, EX-03 A—pending
AU-08 Versioned evidence, exceptions, truthful maturity/claims and distinct delivery/product ledgers A All stages and any status assertion Gate/evidence links, dated decision, bounded claim and exception expiry FDE lead Gate owner; communications/counsel for external claims #mandate, #evidence, #adoption, EX-04/05 A—pending
AU-09 Customer-witnessed scoped acceptance distinct from production and platform adoption A Acceptance request Charter criteria, adverse tests/traces, residual risks, pass/fail FDE lead Customer acceptance owner; Decentra delivery lead #g2, #g5, #evidence A—pending
AU-10 Customer-run operational handoff within agreed scope, no implied perpetual support A Transfer Runbook, monitoring, training/handoff evidence, support and credential disposition FDE/support lead Customer operations owner and Decentra support owner #g6, #evidence A—pending
AU-11 IP provenance and quarantine; no cross-customer reuse without artifact-specific clearance A Creation of candidate artifact Creator/source/dependencies, repo, rights map and restriction flag FDE technical lead IP counsel and security before reuse; product owner for admission #g3, #g6, #evidence, LE-02 A—pending
AU-12 Productization is separate from FDE acceptance; cleared admission needs tests and owner A Candidate for common core Legal/security clearance, generalized test/version/maintenance decision Product owner IP counsel, security and product owner #mandate, #g6, PR-01 A—pending
CB-01 Customer-specific NDA/data processing, transfer, retention or data residency controls B Actual protected data, cross-border/third-party processing or contractual locale limit Data/role/jurisdiction map, effective terms, allowed region and flow Privacy/security owner Counsel and customer data/privacy authority #controls, SE-01, Phase 1 L3; not all engagements transfer data B—open
CB-02 External AI/subprocessor tool, training, prompt/log/backup and output conditions B Any customer material proposed for external model/vendor Model/recipient/data inventory, terms, customer approval, no-training/retention decision Security/privacy owner Counsel and customer data/tool authority #controls, #g4, SE-01; data-use approval is not AI export permission B—open
CB-03 Contractual subcontractor consent, vetting, flow-down and replacement B Outsider/subcontractor or staff change subject to terms Executed clause, consent, due diligence and roster FDE lead/HR Counsel and customer authorized contract/access authority #controls, SE-02, Phase 1 L4; not every employee change requires customer consent B—open
CB-04 PCI DSS cardholder-data and service-provider responsibilities B Actual cardholder-data environment or applicable client/assessor/network obligation Card-data/role boundary, counsel applicability finding, written allocation and validation if required Security/compliance owner Counsel and customer PCI/data/network authority #roles, #controls, LE-03, Phase 1 L6; no blanket PCI certification B—open
CB-05 Card-network registration, validation and operating rules B Specific network role, rail, client flow-down or service-provider status Network/role/contract mapping, applicable rule and registration evidence if required Payments compliance owner Counsel and customer network authority #qualify, #roles, LE-03; no universal registration B—open
CB-06 GLBA Safeguards or bank-interagency security obligations/flow-down B Actual covered entity, data, bank service or signed bank terms Entity/activity/data classification, primary-text and contract review Privacy/compliance owner Counsel and customer bank/privacy authority #controls, LE-03, Phase 1 L6; distinguish bank and nonbank regimes B—open
CB-07 Bank examiner access, records and supervisory third-party duties B Regulated bank engagement and applicable law/contract/exam scope Entity/service map, counsel-reviewed examination/retention clauses Compliance owner Counsel and customer bank/exam authority #roles, LE-03, Phase 1 L6; supervisory guidance is not a blanket statute B—open
CB-08 Reg S-P, securities-recordkeeping or broker-dealer-related flow-down B Covered customer/entity, customer-information or contractually relevant activity Regulated role and information map, counsel primary-text review, signed flow-down Privacy/compliance owner Counsel and customer regulated/compliance authority #controls, LE-03, Phase 1 L6; no assumed broker-dealer FDE mandate B—open
CB-09 External incident notice and independent clock/recipient matrix B Incident potentially meeting a specific contract, network or regulatory trigger Trigger/entity/recipient/clock matrix from signed terms and verified law, decision log Security incident lead Counsel and customer incident/regulatory authority #controls, LE-03/SE-04, Phase 1 L5; four-hour disruption, 36-hour bank, 72-hour provider and 30-day concepts are distinct, not universal deadlines B—open
CB-10 Regulated human credit/fraud/dispute/fund decisions and payment authority B Journey actually delegates or affects such regulated decisions/live funds Decision-rights and legal-role map, approval and rollback FDE technical lead Counsel and customer regulated/payment authority #qualify, #g3, #controls, Phase 1 L6 B—open
CB-11 SOW-specific AI evaluation, support/SLO, training and acceptance measures B AI output or negotiated service/acceptance scope Executed criteria, dataset/threshold/test and support schedule FDE lead Counsel for paper and customer acceptance/operations authority #g2, #g5–#g6, #evidence; no arbitrary targets B—open
CC-01 Foreground/background ownership, license-back and residual hierarchy C Negotiating customer IP terms or reuse Counsel-approved alternative and signed artifact rights schedule IP counsel Authorized contractual signatories and customer rights owner #roles, #approval-register LE-01; playbook alternatives conflict OPEN
CC-02 Generalized derivatives, cross-client reuse and AI-output/IP indemnity allocation C Proposed reuse/indemnity clause or customer artifact Clause and artifact-specific restrictions, dependencies, signed allocation IP counsel Authorized signatories; security and product for actual reuse #controls, LE-01/02/04, Phase 1 L1–L2 OPEN
CC-03 Liability cap/base, exclusions, AI loss and indemnity carve-outs C Negotiated commercial risk allocation Counsel-reviewed clause options, approved deviation and executed terms Counsel/commercial owner Authorized signatories and risk owner #approval-register LE-04, Phase 1 L1; no universal damages classification OPEN
CC-04 Modular agreement architecture: MSA or equivalent, SOW, conditional DPA/Security/AI/Payments schedule C Need for binding discovery/build/access terms Counsel applicability/precedence record, approved form or equivalent, executed instruments Counsel and FDE lead Authorized customer/Decentra signatories, security where relevant #g2, #controls, LE-04; no universal MSA for public/synthetic discovery OPEN
CC-05 Prices, exploratory subsidy, margin, staffing/capacity and payment authority C Commercial offer, budget or funding exception Approved budget, price/payment terms, capacity and authorized signer Commercial/finance owner Finance and executive/commercial signatory; customer signer for deal #mandate, #qualify, FI-01; model is not a target OPEN
CC-06 Publicity, customer naming and external partner/network/finance claims C Any external claim or publicity permission request Source-backed bounded claim, consent and written release Communications/commercial owner Executive communications, counsel and customer where required #controls, #approval-register EX-04; no inferred partner status OPEN
CC-07 Acceptance/remediation mechanics, change rights and support/wind-down C Drafting deal-specific acceptance and service clauses Signed SOW criteria, cure/decision route, handoff/support boundaries FDE/commercial lead Counsel and authorized customer/Decentra signatories #g2, #g5–#g6, LE-04; no automatic platform purchase OPEN
CC-08 Internal one-hour incident objective and staffed coverage C Proposal to adopt the playbook clock as organizational commitment Owner-approved route, coverage/back-up and exercise Security incident lead Security incident commander and executive/FDE practice owner #controls, SE-04, Phase 1 L5; immediate escalation proposed under AU-06, clock not ratified OPEN
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.

PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

Productization Candidate Register and decision procedure

Download blank candidate register CSV · Private project file; values must be authorized before use.

Candidate handling does not delay independently accepted customer FDE work. No customer-derived component enters common core on an engineer’s assertion of generality. Every decision requires a decision rationale and follow-up owner.

  1. Spot and log (Discover, #g1). FDE technical lead notes a repeatable problem or candidate interface in the engagement's access-controlled evidence system; create a candidate ID and confidential source reference. Record what is observation versus actual artifact and the approved environment. Do not export a customer document, code, diagram, data, logs, prompts, secrets or identifying description into a common backlog. A sanitized requirement can be triaged only after confidentiality screening; a requirement idea is not a shared component.
  2. Describe and segregate (Design, #g3). Attach the ADR and provenance record: technical boundary, component/version/repository or proposed location, creators/contribution dates, customer and Decentra pre-existing material (background), newly created work (foreground), any claimed residual know-how, third-party/open-source dependencies, contract/deliverable schedule/version and known restrictions. Mark classification disputed or unknown rather than guessing ownership. Keep customer-specific forks inside their approved access boundary. An architecture diagram or generalized interface does not confer copy rights.
  3. Flag and stop at the boundary (Deliver, #g4). On an invention or proposed reuse, FDE lead opens/updates the register and quarantines customer-derived implementations and evidence from shared repos, other customers, demos, training/AI tools and external disclosures. Continue only authorized Lane A delivery in the agreed customer environment; stop the affected replication or transfer before any cross-customer copy/reuse, including apparently generalized code, designs, tests or derived data. Re-charter material changes of data, tool, access, personnel or effects under the existing gates and authorization states. There is no exception that supplies missing contract rights or customer consent.
  4. Decide rights and safety before movement (Design/Deliver/Transfer, before any cross-context use). IP counsel checks the actual executed instrument and artifact-specific ownership, background/foreground allocation, assignment, license-back, residual/general-application wording, confidentiality, deliverable restrictions and third-party licenses; record clause/version, allowed acts/contexts, limits, necessary customer approval and written counsel disposition. Security/privacy reviews confidential content, data/secret leakage, regulated information, allowed environment, sanitization and test-fixture provenance; record written clearance or blocker. De-identification, generalized wording, a clean-room proposal or a right to remember residuals is not automatically permission to reuse. If terms are ambiguous, approvals missing or security review fails: keep restricted and do not copy; seek counsel/customer rights, remove material under review, or propose independently developed work only after counsel clears the restrictions. No cross-customer access while pending.
  5. Product decision (Transfer, #g6, or later). In recurring FDE–product triage, the proposed product owner evaluates independently useful scope, platform relevance, generalized interface, limitations, versioned implementation, reproducible tests (including adverse/security cases), dependency/license inventory, release plan, named final maintenance/support owner and cost. Record one final disposition from the four below, rationale, decision date and next owner. Promote to core platform requires written artifact-specific contractual rights, any required customer permission, confidentiality/security clearance and product-owner signoff accepting tests, version and maintenance; only then move approved material through controlled repository/release review. Promotion is not production readiness, license sale or permission to disclose the source engagement. Retain as customer-restricted keeps a controlled fork for the authorized customer. Defer leaves the candidate quarantined with an explicit prerequisite and revisit owner/date. Reject closes the candidate without replication, observing existing retention/deletion duties. New facts require re-review and a dated superseding record, not silent status change.
  6. Verify independently later. Record actual second-context reuse only after separate rights/access clearance for that context: approved context reference (confidential), authorized version, integration/test evidence, date, effort baseline and observed effort, defects/support impact and evidence links. Blank means unverified, not zero or success. Customer acceptance and transfer proceed on their own dossier even if the product decision is pending. Keep executed platform order/license, production release and usage in the distinct commercial/release ledgers; do not infer them from a candidate or promotion.

Decision ownership: FDE technical lead maintains provenance and quarantine; engagement lead enforces delivery boundary; counsel/IP owner determines rights and customer permission; security/privacy owner determines safety; Decentra product owner alone accepts core scope and maintenance; customer authorized rights/data authority approves where actual terms require it. A reviewer cannot substitute for another authority. Apply controls-increment.md AU-03 (confidentiality), AU-08 (two ledgers/evidence), AU-11 (provenance/quarantine), AU-12 (separate product admission), CB-01/02 (triggered data/AI restrictions), CC-01/02 (unresolved IP and derivative clauses), CC-06 (publicity) and the existing source-index.html#controls exceptions. These are proposed control classifications, not proof of ratification or contract effect.

Blank reusable candidate register

Store only in an approved access-controlled system; the register's source reference is confidential, not a customer name for public reporting. Links to actual contracts, code and tests must respect their access controls. Do not prefill facts or approvals. The disposition cell must contain exactly one of the four enumerated values below when a decision is made; while undecided leave it blank, with the item quarantined. Quarantine is a handling control, not a fifth disposition. Keep superseded decisions as dated history.

Candidate ID Source engagement (confidential reference) Technical description; component/version/repository or proposed location; creators/dependencies Business/platform relevance and proposed general interface Background / foreground / residual classification and provenance evidence Customer confidentiality / data class and permitted environment Executed contract identifier/version; permission/restriction; customer approval; counsel disposition/date/evidence Security/privacy disposition/date/evidence Technical/test evidence, limits and release/version plan Proposed product owner Final product and maintenance/support owner; signed acceptance evidence Decision date Disposition (one of exactly four below) Rationale Next action / owner / review date Actual second-context reuse: separately permitted context reference, version, approval, integration/test and effort/defect/support evidence

Allowed disposition values (use verbatim):

  • Promote to core platform
  • Retain as customer-restricted
  • Defer
  • Reject

Register handling: retain a restricted reference to the underlying evidence, access owners and change history; do not paste customer-protected material into this template or a cross-account report. An empty counsel, security or owner-signoff cell is a blocker to promotion. A second-context claim requires its own permission and observed evidence, even if the original artifact was promoted. Disposition is not a commercialization event.

Measured outcomes

Use a fixed reporting period and internal, permissioned IDs; count candidates rather than engagements and publish only aggregates after confidentiality/publicity review. Record numerator, denominator, period, cohort/version, data provenance and missing-data count. Suppress small cells or group periods when an identity or protected implementation could be inferred; no code, architecture, contract clause, customer name, system details or trace in an external metric. Do not invent baseline targets.

  • Disposition coverage: candidates with a dated one-of-four decision / candidates logged in the cohort; show counts by the four dispositions and pending separately (pending is not a disposition).
  • Clearance quality: promoted candidates with linked counsel, security/privacy and product-owner evidence / all promoted candidates; track blocked or revoked cases internally and stop use if a permission expires.
  • Actual reuse: promoted candidates with independently permitted, tested second-context use / eligible promoted candidates; report separately those merely promoted and those reused. Compare implementation effort against a documented comparable baseline, plus defects/support load and confidence/missing-baseline count; do not call a projection measured savings.
  • Delivery separation: customer FDE acceptance/pass-fail and transfer/handoff counts from Lane A dossier, separately from product admission, authorized production release and signed platform license/realized usage from their own ledgers. No candidate count is software ARR, merchant activation or production deployment.
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

Download blank overlay CSV · Private project file; values must be authorized before use.

All values and approval evidence are BLANK. Fill only from a dated, authorized source; no Payroc contract, journey, access, architecture, payment effect or launch is claimed.

Required fieldValueVerification/approval evidence
01 Standard version, status, overlay version and inherited gates[BLANK][BLANK]
02 Company legal entity/counterparty, jurisdiction, regulated/network role[BLANK][BLANK]
03 Customer sponsor, contractual signer, system/data/security/payment/operations owners; Decentra counterparts/backups and decision delegation[BLANK][BLANK]
04 One selected journey, outcome, exclusions, first environment and reason for FDE[BLANK][BLANK]
05 Actors; agent identity/authentication, delegated consent, scope/expiry/revocation, human/payment/fund/risk authority; merchant/order/payment systems of record[BLANK][BLANK]
06 Interfaces/rails, credentials, test environment, data classes/flows, client-approved enclave, external AI/tools/logs/backups and access expiry[BLANK][BLANK]
07 Selected readiness dimensions, baseline, status per environment, risks and evidence[BLANK][BLANK]
08 Paper/approval: executed applicable instrument(s), versions/signers/effective dates, discovery versus build authority, SOW/price/change route, triggered schedules and counsel determination[BLANK][BLANK]
09 Named staff/subcontractors and consents, least-privilege access, risk/security/privacy and regulatory/network applicability decisions[BLANK][BLANK]
10 Authorization-state transition record and #g0–#g6 artifacts/exits: permitted/excluded activity, customer/Decentra approvers, timestamps, blockers, expiry, stop/re-charter route[BLANK][BLANK]
11 Acceptance/recovery: customer-witnessed positive/adverse tests, denial/replay/timeout/uncertain outcomes, reconciliation, AI thresholds only if scoped, pass/fail and remediation[BLANK][BLANK]
12 Separate production gate: named change/payment authority, live effects, security tests, monitoring, incident route, reconciliation, pause/rollback and release signoffs; support/handoff/training/SLO only if contracted[BLANK][BLANK]
13 Commercial/IP: background/foreground/residual and third-party rights, restricted deliverables, candidate legal/security/product disposition and any separately executed platform/license/channel terms[BLANK][BLANK]
14 Local exceptions: control, reason, mitigation, authorized customer/Decentra signers, expiry/review/rollback; never rights waiver[BLANK][BLANK]
15 Delivery economics and observed outcome evidence versus optional platform/usage/downstream distribution hypothesis and actual receipts[BLANK][BLANK]
16 Open facts, evidence links, confidentiality/publicity restriction, next owner and due-before gate[BLANK][BLANK]

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.

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.

PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

B / Detailed v0.1-to-v1 change log

Archived v0.1 is a provisional comparison baseline; the public URL’s historical contents and approval chronology are unproven. All approvals remain OPEN. Gap closures are CH-09–CH-12.

Change IDOriginal sectionRevised sectionChange typeOriginal rule / wording (paraphrase)Revised rule / wording (proposal)RationaleSource evidenceApproval implications; owner/date status
CH-01v0.1 §01v1 #mandatePreserve/tightenbounded embedded journey, smallest primitive, two ledgers and no assumed custodypayments-infrastructure-only eligibility, generic AI consulting excluded, Lane A independently accepted while Lane B product/license/usage is optional and separately evidenced.Constrain mission and avoid inferred platform adoptionArchived §01; staged #mandate; Phase 1 §§2–3; funding report cited there is context, not contracted demand.EX-01 perimeter, EX-02 delivery economics, FI-01 metrics, GO-01 ratification OPEN; executive/FDE/finance must approve. Decision owner/date: OPEN.
CH-02v0.1 §02v1 #qualifyExtendsponsor, accessible boundary, baseline, economic case and defer/declinepayment actor/rail/funds/data/authority screen, journey-and-environment readiness statuses, capacity and channel as hypothesis, discovery rather than unauthorized implementation.Make selection/readiness measurableArchived §02; staged #qualify; Phase 1 §§2–3.EX-01/02, FI-01, LE-03 and SE-01 OPEN; no prospect becomes an authorized build. Decision owner/date: OPEN.
CH-03v0.1 §03 gates 00–06v1 #lifecycle, #g0–#g6Preserve/extendSeven owner/artifact/exit gates and separate production decisionPreserve all seven owner/artifact/exit gates; extend Intake mission fit, Discover access/baseline, Charter effective paper and scoped acceptance, Design authority/rights/data, Deliver synthetic-first/test evidence, Accept adverse paths and explicit separate live release, Transfer customer-run handoff and rights-screened candidate. No gate removed or automatically advanced.Preserve gates while making exits executableArchived §03 and gate exits; staged #g0–#g6; Phase 1 §2 seven-gate map.EX-02/03, LE-01–04, SE-01–03, PR-01 OPEN; customer-specific gate approvals still separately required. Decision owner/date: OPEN.
CH-04v0.1 §04v1 #rolesPreserve/extendExtend named DRI and distinct partner/Decentra technical, product, risk and operations rolesauthorized contract/IP, regulatory/network, incident, production and publicity signers with domain vetoes. Product owner cannot confer contract rights.Name domain signers and vetoesArchived §04; staged #roles and decision table; Phase 1 §§2,4–5.EX-02/03/04, LE-01/03, SE-01/03/04, PR-01 OPEN; named people/delegations must be recorded before action. Decision owner/date: OPEN.
CH-05v0.1 §05v1 #controlsPreserve/extendLeast privilege, revocation, synthetic preference, consent and expiring exceptionsPreserve least privilege, revocation, synthetic/sandbox preference, separate consent/payment authority and expiring exceptions; clarify client-approved data enclave is not export/AI permission, roster/subcontractor consent, immediate internal incident route versus conditional external clocks, security testing and separate release, applicable paper only.Protect data, authority and conditional noticesArchived §05; staged #controls; Phase 1 §§2,4 and §7 C4/C7; playbook Parts I/IV–V are not counsel-approved law.LE-03/04, SE-01–04, EX-05 OPEN; one-hour objective and regulatory duties not blanket adopted obligations. Decision owner/date: OPEN.
CH-06v0.1 §06v1 #evidencePreserve/extendExtend seven-artifact opportunityhandoff pack with effective terms/access, selected readiness evidence, rights/provenance, release/incident and separate delivery/product/commercial ledgers with denominators and provenance.Separate delivery and commercial evidenceArchived §06; staged #evidence; Phase 1 §§2,6–7.EX-02/03, FI-01, LE-02, PR-01 OPEN; model figures and claimed reuse do not count as results. Decision owner/date: OPEN.
CH-07v0.1 §07v1 #inherit, #payroc-templatePreserve/extendSeparate company overlay and no silent gate deletionPreserve separate company overlay and no deletion of gates; extend with entity/rail/jurisdiction, contract, staff/data/AI, authority, scoped acceptance, production, support and IP fields; blank Payroc schema is not an account assertion.Preserve global/customer separationArchived §07; staged #inherit and 16 fields at #payroc-template; Phase 1 §2.EX-02/03, LE-03/04, SE-01/02 OPEN and real customer signers required for a populated overlay. Decision owner/date: OPEN.
CH-08v0.1 §08v1 #adoptionPreserve/extendPending status, stewards, version and review cadencePreserve pending status, stewards, version/review cadence; require dated multidomain owner ratification, evidence repository, migration and separate confidentiality/publication clearance.Prevent premature policy adoptionArchived §08; staged #adoption; Phase 1 §§1,2,9.GO-01/EX-04 OPEN; private RC is not adoption or public authorization. Decision owner/date: OPEN.
CH-09v0.1 §§02–03/05–06 (no unified transition record)proposed #qualify, #g0–#g3, #evidenceNew Gap 1No unified state-transition authorization recordstate 1 bounded public/synthetic/non-sensitive discovery; state 2 separately authorized limited/sensitive discovery; state 3 effective instrument and scoped committed implementation; state 4 separate named production-effect authorization. Record permitted/excluded actions, instrument/version/signers/effective date, customer authority, staff/subcontractors, data/tool/environment/access, expiry, risk/payment/commercial approvals, timestamp/link and stop/re-charter outcome. No universal MSA for public/synthetic work; no unsigned SOW or casual invitation as sensitive/build permission.Close pre-engagement authorization ambiguitybaseline-inventory.md Gap 1; controls-increment.md Gap 1; staged #qualify, #g0–#g3, #evidence; Phase 1 §2.EX-02/03, LE-04, SE-01/02/03 OPEN; counsel and actual customer authority approve triggered entry. Decision owner/date: OPEN.
CH-10v0.1 §05 (guardrails but no applicability table)proposed #controls, #roles, #approval-registerNew Gap 2Guardrails lacked per-control applicability classificationAU intended universal field conduct if ratified, CB conditional on actual entity/role/rail/data/environment/contract/AI/live funds, CC proposed legal/commercial terms OPEN. Per-control trigger, evidence, responsible owner, veto and status; no exception-waiver of binding rights.Differentiate universal, triggered and proposed controlsbaseline-inventory.md Gap 2; controls-increment.md AU-01–12, CB-01–11, CC-01–08; staged #controls; Phase 1 §§4,7.GO-01 global approval and LE/SE/EX/FI domain decisions OPEN; applicability is not established by a matrix row. Decision owner/date: OPEN.
CH-11v0.1 §§01/03/06 (candidate/reuse note only)proposed #g3, #g4, #g6, #evidence, #boundary-matrixNew Gap 3Candidate/reuse note lacked formal dispositionrestricted candidate ID/provenance and quarantine before any cross-context copy; artifact-specific counsel rights and security/privacy clearance; product owner accepts tested version/maintenance. Final disposition only Promote to core platform / Retain as customer-restricted / Defer / Reject; separately prove permitted second-context use. Lane A transfer proceeds independently unless actual signed scope says otherwise.Require an owned four-way product dispositionbaseline-inventory.md Gap 3; productization-increment.md procedure/register; staged #g3/#g4/#g6, #evidence; Phase 1 §§3,5.LE-01/02, SE-01, PR-01 OPEN; no default ownership/residual/copy right. Decision owner/date: OPEN.
CH-12v0.1 §§01–08 (no integrated governance companions)v1 existing #change-log, #approval-register, #boundary-matrix, #payroc-template, #open-decisions, #source-boundary and new #claims-registerNew Gap 4No integrated traceable A–G governance packagetraceable A–G package, explicit source limits and claim-by-claim publicity gate. Existing six companion anchors remain; new G is an insertion, not a rewrite of the eight-section core.Make the A–G review package discoverablebaseline-inventory.md Gap 4; staged companion anchors and Phase 1 §§1,7,9; this artifact.GO-01/EX-04 OPEN; owner must approve package/version, evidence and release wording before any circulation beyond authorized private review. Decision owner/date: OPEN.
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

C / Formal approval register

Unresolved engagement access/build/production decisions block the affected activity, including any engagement expansion into it; policy-ratification decisions block adoption, and external-claim decisions block publication. Customer-specific authorization is separate from global approval. Every row remains OPEN pending actual signer, date/timezone, evidence link and conditions.

Decision IDOwner roleStatusBlocker classConsequence if unresolvedEvidence requiredSection linkSigner/date/evidence status
EX-01executive sponsor + FDE practice ownerOPENpolicy ratificationPayment perimeter/edge exceptions cannot be adoptedwritten eligibility and delegated exception rule.#mandate, #qualifyNamed signer/date/timezone/link: OPEN
EX-02executive/commercial signatory + FDE lead; counsel for paperOPENengagement access/build/productionNo committed work or unbounded subsidy/scope changedelegation, funded/timeboxed discovery, effective instrument and authorized SOW/scope.#qualify, #g0–#g2Named signer/date/timezone/link: OPEN
EX-03customer change/service/payment authority + Decentra technical/security/support, applicable counsel/commercialOPENengagement access/build/productionNo live effectnamed release/rail/environment, customer authorization, tests, monitoring, reconciliation, rollback and support signoffs.#g5, #g6, #rolesNamed signer/date/timezone/link: OPEN
EX-04executive communications owner + counsel + customer/counterparty as requiredOPENexternal claimNo naming or external patent, partner, certification, financing or performance claimG claim record, primary proof, consent and written release.#controls, #source-boundary, #claims-register (new)Named signer/date/timezone/link: OPEN
EX-05executive sponsor + affected risk/legal/customer authorityOPENpolicy ratificationNo adopted exception delegationdefined no-waiver set and scoped exception form with mitigation/expiry. Cannot cure absent rights/consent.#controls, #adoptionNamed signer/date/timezone/link: OPEN
LE-01IP counsel + authorized executive signatoryOPENpolicy ratificationNo default foreground/background/residual hierarchycounsel-approved clause alternatives and actual signed artifact terms.#roles, #boundary-matrixNamed signer/date/timezone/link: OPEN
LE-02IP counsel + security/privacy + product owner; customer rights authority if requiredOPENengagement access/build/productionNo cross-account copy/core admissionartifact-specific contract/version, provenance, licenses, consent, security and product clearance.#g3–#g6, #evidenceNamed signer/date/timezone/link: OPEN
LE-03regulatory counsel + customer regulated/network authority + security incident leadOPENengagement access/build/productionNo asserted PCI/network/bank/GLBA/Reg S-P duty or notice clockentity/activity/rail/data/jurisdiction map, primary text, signed flow-down, distinct trigger/recipient/clock finding.#qualify, #roles, #controlsNamed signer/date/timezone/link: OPEN
LE-04counsel + authorized customer/Decentra signatoriesOPENengagement access/build/productionNo sensitive access or committed build without adequate effective instrument and scopeapproved MSA/equivalent, SOW and triggered DPA/Security/AI/Payments schedules with execution/precedence and staffing/publicity/liability terms.#g1, #g2, #controlsNamed signer/date/timezone/link: OPEN
SE-01security/privacy owner + customer data authority; counsel for transfersOPENengagement access/build/productionNo unapproved client data/AI processing or exportdata flows/enclave, retention, model/log/backup path, assessment and explicit tool/transfer approvals.#controls, #g1–#g4Named signer/date/timezone/link: OPEN
SE-02security/HR + FDE lead + customer access authority where requiredOPENengagement access/build/productionNo unauthorized person/subcontractor accessnamed roster, vetting/consent/flow-down, least privilege, expiry and revocation record.#g2, #controls, #evidenceNamed signer/date/timezone/link: OPEN
SE-03security lead + customer change authorityOPENengagement access/build/productionNo live transitionthreat/adverse tests, remediation, release, monitoring, incident, rollback and residual risk evidence.#g3–#g5, #controlsNamed signer/date/timezone/link: OPEN
SE-04security incident commander + executive/FDE practice ownerOPENpolicy ratificationOne-hour internal objective/on-call coverage cannot be promised as approveddocumented immediate escalation route, staffing/backups and exercise; external clocks separately LE-03.#controls, #adoptionNamed signer/date/timezone/link: OPEN
FI-01finance lead + executive/commercial ownerOPENpolicy ratificationNo adopted price, subsidy, margin, staffing or modeled targetapproved budget/contribution basis, capacity, finance metric definitions and authoritative dated model.#mandate, #qualify, #evidenceNamed signer/date/timezone/link: OPEN
PR-01product/engineering owner after legal/securityOPENpolicy ratificationNo global product admission rule treated as ratifiedcandidate register, test/version/release and maintenance criteria, rights/security veto. Individual candidates need separate decisions.#g6, #evidence, #boundary-matrixNamed signer/date/timezone/link: OPEN
GO-01executive sponsor + FDE practice owner + counsel + security/privacyOPENpolicy ratificationv1 stays a private proposalapproved exact version/hash, domain dispositions, named stewards, effective date, repository/access, migration and review record. Public derivative also needs EX-04.#adoption, #approval-registerNamed signer/date/timezone/link: OPEN
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

D / Engineering and commercial boundary matrix

Ownership below is a decision route, not a finding that Decentra owns any specific foreground work. Executed agreement, permissions, confidentiality, third-party licenses and law decide actual rights. Production authorization and outward claims remain independent of both delivery and product admission.

Workstream Accountable ownership / output Authorization and acceptance evidence Reuse and commercial boundary
Core platform (Lane B) Decentra product/engineering owner maintains independently cleared general capabilities and version/support plan; background IP only as established by records/terms. Internal roadmap, provenance, tests, security, release and maintenance acceptance; any customer license requires its own executed order. No customer-derived foreground without artifact-specific legal/security clearance; feature existence ≠ full-stack production certification, sale, usage or merchant activation.
FDE integration (Lane A) FDE lead + customer sponsor/system owner for one bounded journey, tests, acceptance dossier and customer-run handoff. Phase-specific authority, effective scope/SOW for build, agreed environment/people/data, signed acceptance and support boundary; separate live release. Customer acceptance stands alone; it does not grant platform procurement, IP reuse, network status or continuing revenue.
Customer customization FDE technical lead + customer system owner; adapter/configuration/fork in approved customer boundary; foreground allocation unresolved until actual paper. Versioned SOW/deliverable schedule, data/access consent, tests and customer acceptance/transfer. Restricted fork by default pending artifact-specific contract, customer rights and security decision; no other-account code/design/data/log copy.
Reusable development candidate FDE technical lead records source/creator/dependencies; IP counsel and security/privacy veto movement; product owner accepts tested core/version/maintenance. Confidential candidate ID and ADR → quarantine → executed rights/third-party/customer consent check → security clearance → product disposition (Promote / Retain restricted / Defer / Reject), with dated evidence. General idea ≠ rights-cleared component. Independently developed alternative still needs counsel review. Second-context reuse needs separate permission, tests and measured evidence; no automatic license.
Restricted deliverables Customer/Decentra custodians and authorized contract/data owners under actual terms; include customer foreground, protected data, secrets, bespoke code, traces, prompts and derivative designs where restricted. Effective engagement terms, restricted repository/enclave/access roster, retention/deletion and customer handoff record; explicit scoped acceptance if contracted. No movement to shared repos, other customers, external AI, demos, publication or general training while rights/confidentiality/security unresolved. Exception cannot create a license.
Commercial/distribution relationship Commercial owner + finance + actual customer channel authority; services, optional license/usage or downstream channel are distinct. Approved price/budget and actual signed order/license/channel terms; finance definitions, realized telemetry and attribution. Forecast, pilot, customer base or FDE acceptance is not recognized ARR, distribution right or merchant activation.

Lane A to Lane B admission: restricted customer fork → candidate ID/provenance → counsel and security/privacy artifact-specific decisions → product-owner tested/versioned maintenance acceptance → controlled core promotion. Candidate register. FDE acceptance, production release and executed platform license are separate records.

PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

F / Consolidated open decisions and owners

All statuses OPEN. Due-before is a dependency, not an invented calendar date. Duplicate questions are consolidated under one F ID.

All statuses OPEN. “Due before” is a dependency, not a fabricated calendar deadline. IDs consolidate overlapping questions from staged #open-decisions, #approval-register, Phase 1 §§4–7, controls-increment.md and productization-increment.md; do not open duplicate tracks for the same choice.

F ID / domain; linked C IDs Decision and accountable owner roles Dependency; due before what
F-01 strategic/governance; EX-01, GO-01 Executive sponsor + FDE practice owner choose canonical v0.1/live/private baseline, payments-only perimeter/edge exceptions, stewards, approved version and migration/distribution. Version provenance and domain approvals; before global ratification or representing v1 as effective.
F-02 operational/engagement; EX-02, LE-04 Commercial signatory + FDE lead + counsel settle phase-specific discovery/build instruments, scope/SOW, authorization states, delegation, change/stop rules and staff capacity. Actual counterpart authority and effective documents; before sensitive discovery or committed build respectively. Public/synthetic bounded work need not universally await an MSA.
F-03 operational/production; EX-03, SE-03 Customer change/payment/service authority + Decentra technical/security/support and applicable counsel/commercial owners settle live-effect signers, testing, rollback, reconciliation, operations and acceptance separation. Effective scope and environment-specific proof; before each production-impacting release, not at FDE acceptance.
F-04 legal/IP/product; LE-01, LE-02, PR-01 IP counsel + authorized signatory choose foreground/background/residual hierarchy and contract fallbacks; security/privacy and product owner set per-candidate rights, quarantine, four-way disposition and core maintenance criteria. Actual signed terms, provenance, third-party licenses and any customer consent; global policy before ratification, artifact decision before any cross-context copy/admission.
F-05 legal/regulatory/security; LE-03, SE-01 Counsel + customer regulated/data/network authorities + security/privacy classify actual role/rail/jurisdiction/data, DPA/transfers/AI, PCI/network/bank/GLBA/Reg S-P flow-downs and distinct incident notice triggers. Primary law and executed terms plus data/authority map; before affected access/live activity or external notice assertion.
F-06 security/people/incidents; SE-02, SE-04, EX-05 Security/HR + incident commander + FDE practice owner define roster/consent/revocation, immediate escalation/backups, whether one-hour internal objective is staffed, and exception no-waiver/expiry. Actual staffing and applicable customer terms; before access and global operational promise; external clocks require F-05.
F-07 finance/commercial; FI-01, EX-02 Finance + executive/commercial owner approve exploratory subsidy, contribution/margin, capacity/hiring, pricing/payment delegation, accounting definitions and dated authoritative model. Actual budget, terms, cash evidence and reconciled report/model/deck scope; before commercial offer, staffing commitment or target/public forecast.
F-08 product/operations; PR-01, EX-03 Product/engineering owner and customer operations + Decentra support owner set recurring product triage/test/version ownership and handoff minimum versus SOW-specific training/SLO/support. Rights-cleared candidate and actual service terms; before core promotion or operational handoff, without delaying signed Lane A acceptance for unrelated product review.
F-09 external claims; EX-04, GO-01 Executive communications + counsel + finance/security/product and counterparty/customer rights owner as relevant resolve partner/investor/patent/certification/maturity/deployment/merchant claims and permission. G proof and written consent/release, including contradictions Phase 1 §7 C1–C3/C9/C10; before any external wording/public derivative.
PRIVATE RELEASE CANDIDATE · OWNER APPROVAL PENDING

G / Evidence and claims register

Use one row per bounded claim and version; owner records source date/version, exact claim text, intended audience/channel, verification status, proof link, rights/consent, publicity approver, decision/date/expiry and recheck trigger. Below, “allowed internal wording” is for restricted review only, not a statement approved for public use. Publicity approval status for every row: OPEN; EX-04 is the release gate. Classifying an assertion as documented means only that the artifact says it, not that the underlying event occurred. No source here supplies primary signed partner, investor, patent, certification, deployment or production evidence. The funding report and pro forma are context, not realized results; the playbook is not counsel-approved law.

Claim ID; evidence class Source locator and allowed internal wording Proof needed for stronger or external claim; publicity owner/status
CL-01; directly documented artifact fact archived-v01.html header/§§01–08; source-index.html title, banner, #mandate–#adoption, #change-log–#source-boundary; baseline-inventory.md lines 5–8. “The staged proposed v1 and provisional archived v0.1 each contain eight core sections and seven gates; their provenance and approval history are unresolved.” Canonical dated baseline, version/change history and owner-signed adoption record before claiming an effective version. Executive/FDE owner + counsel; OPEN.
CL-02; directly documented artifact fact with source limit phase1-review.html §1 reports a separately fetched public URL with a different byte count/hash than the archive; this workspace did not refetch it. “Phase 1 reported a differing publicly reachable snapshot; do not equate it to this private proposal.” New dated capture, deployment history and owner/publication record before asserting current URL content or chronology. Executive/FDE + communications; OPEN.
CL-03; internal assertion Phase 1 §7, playbook Part I §1 (three identified launch clients), and cited October deck 06–07 (Visa participation, Payroc/Suede programs). “Internal materials assert prospective or later partner/program relationships; counterpart status is unverified here.” Dated executed counterpart terms, scope/work evidence and naming consent; distinguish discussions, signed program, investment and live deployment. Executive communications + counsel + counterpart; OPEN.
CL-04; strategic hypothesis source-index.html#mandate, #qualify, Phase 1 §§1,7; playbook Part I §1 and funding report “Implication for Decentra” as cited. “A rights-cleared FDE integration may inform a reusable platform capability or channel; neither follows automatically.” Candidate-specific rights/security/product evidence, independently permitted second use, signed channel/license and observed activation with attribution. Product + commercial + counsel; OPEN.
CL-05; financial assumption/model output phase1-review.html §§6–7 C1/C2/C8; staged #mandate, #open-decisions. “The report describes historical/planned financing and the draft High-case workbook models pilots, hiring, cash and revenue; these are not receipts, budgets, recognized revenue or targets.” Different vintages and business scopes must not be added. Finance-approved dated model, assumptions/period/entity reconciliation, accounting basis, executed financing and bank/cap-table receipts for actuals; authorized forecast release. Finance + executive + securities counsel; OPEN.
CL-06; historical claim needing corroboration Phase 1 §7 C1/C3: cited funding report “Historical Decentra financing context” and “Partnership and milestones recorded in June” differ from later deck/model claims. “The sources describe different historical plans and later assertions; the underlying events and status changes are not verified.” Contemporaneous signed documents, dated ledger/cap table, bank evidence, counterpart confirmation and chronology. Finance + executive + counsel; OPEN.
CL-07; unverified patent/IP/valuation claim Phase 1 §7 C9 and cited deck 09; staged #source-boundary. “A deck asserts pending filings and management valuation references; neither a grant nor independent value is established.” Filing/application identifiers, official status, ownership/assignments, counsel opinion, independent valuation if claimed and permission to disclose. IP counsel + executive communications; OPEN.
CL-08; unverified partner/network/certification/compliance claim Phase 1 §7 C3/C7 and cited deck 06–07; staged #controls, #approval-register LE-03/EX-04. “Network participation, registration, PCI or other certification and applicable legal duties are unverified and context-dependent.” Specific entity/role/rail and primary-rule analysis, network/assessor records, executed terms, certifier scope/validity and counterpart consent. Regulatory counsel + security + executive communications; OPEN.
CL-09; unverified deployment/product-maturity claim Phase 1 §7 C9, staged #qualify, #g5, #source-boundary; cited deck 04–05/08. “A design, repository, sandbox, demo or pilot is not full-stack production readiness, certification or live transactions.” Scoped version/environment, integration/security tests, customer acceptance, separate live release authorization, telemetry/reconciliation and support evidence for the exact claimed boundary. Product + security + customer release owner + communications; OPEN.
CL-10; unverified legal/operational claim Phase 1 §4/§7 C4–C7; playbook Parts I, IV–V as cited by staged #controls. “Playbook clauses, client-enclave default, internal one-hour objective and example incident clocks are proposals/questions, not counsel-approved universal law or executed duties.” Counsel primary-text and contract applicability by entity/activity/data, approved clause/coverage, customer consent and independent trigger/recipient/clock matrix. Counsel + security incident owner; OPEN.
CL-11; unverified commercial outcome Staged #evidence, #boundary-matrix; Phase 1 §7 C2/C6; draft model. “FDE acceptance, candidate promotion, executed platform license, realized usage, downstream merchant activation and recognized revenue are different evidence states; no account-specific actual is supplied here.” Signed acceptance/order, rights-cleared product decision, metered usage, attributable activation and finance-recognized ledger with denominator/period. Finance + commercial + product + customer publicity owner; OPEN.

Release rule: if proof, rights/consent, intended wording, authorized publicity owner or decision date is blank, classify external use as blocked. A private reviewer may quote the bounded internal wording with source/uncertainty intact; a document merely repeating a claim does not verify it. Reopen on changed scope, expiry, contradicted source or new deployment/financing status. Link G to #source-boundary (snapshot/primary-source limits), #approval-register EX-04, #controls truthful-claims rule and #adoption publication decision; add G / Claims to companion navigation only in a later authorized HTML edit.

PRIVATE RELEASE CANDIDATE · VERIFICATION

Phase 3 review readiness

The scoped Doer verification, independent structure checks, local browser inspection and hosted readback are recorded in the private verification record. This is a GO for Phase 3 adversarial review only, not owner approval, activation, production access or public publication. A broader initial Doer verification attempt failed with a runtime error; two bounded verification runs followed.

DECENTRA FDE OPERATING STANDARD v1 — PRIVATE RELEASE CANDIDATE — OWNER APPROVAL PENDING

Source trail and evidence limits

  • Archived HTML explicitly labeled v0.1, §§01–08 and gates 00–06, is a provisional comparison baseline. The live public URL https://od-decentra-fde-standard-decentra-fde.pages.dev was separately fetched and differs from the archive; its historical provenance, canonical version and approval history are unproven. The live page supplies this proposed visual/navigation shell, not ratification. This privately hosted proposal is not a public Pages update or owner ratification.
  • Decentra FDE Playbook and Team Briefing.docx, Part I §§1–6 (strategic/field guidance), Part III §§1–10 (clause study), Part IV (regulatory issue list), Part V §§126–161 (proposed drafting/caveats). It expressly calls for counsel verification and final agreements; third-party contract characterizations are not adopted as Decentra paper.
  • Decentra-AgenticCommerce and FDE Funding Report-September15 2026.docx, “Implication for Decentra,” “FDE comparison groups,” “Research method and coverage limits,” and “Historical Decentra financing context.” Comparable financing is not Decentra evidence.
  • Decentra FDE-Pro Forma_v2 draft BLN.xlsx: all 14 tabs reviewed in Phase 1; Assumptions!B5 selects High; Assumptions!C24/G24 name modeled pilots; Cash Flow!D20 models a negative pre-close balance. No model number is made a v1 mandate. An isolated LibreOffice copy recalculated 20,484 cached formula results across all 14 sheets within $0.01 absolute or 1×10⁻⁶ relative tolerance; this is cached-result consistency, not Excel, formula-design, accounting or economic validation. The High scenario hypothetically models Month 3 cash −$401,583.33 (bridge to zero); Month 4 cash $405,266.67 after the first modeled seed tranche is still $574,733.33 below the $980,000 reserve floor. Neither funding nor reserve compliance is established.
  • Decentra Seed Round Deck Visual-10_15_2026v1.pptx, slides 4–5 (proposed architecture), 6–13 (partner/financial/IP assertions requiring verification); six non-broker-dealer Decentra repository READMEs for product-boundary context. Neither proves the entire stack production-ready or a live partner integration. Broker-dealer product work is outside this practice scope, without waiving obligations that might apply to a separate regulated customer engagement.
  • phase1-audit.md, §§1–9: contradiction, legal, financial and evidence registers. Signed customer terms, primary regulatory text, financing receipts, patent files, deployment telemetry and product test evidence were not supplied for independent confirmation.

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.