Service Policies for Mandate402 Delivery and Support

Mandate402 programming work starts from a written scope that defines the business problem, the goal, the responsible owner, the acceptance criteria, and what is out of scope. This matters because the product sits between operator intent, paid vendors, and treasury controls, so unclear requests create real delivery and trust risk.

If the client asks for work outside the approved scope, the request is treated as a change request. The provider may pause the new work until the change is written down with its expected impact on schedule, price, dependencies, and verification.

• Scope changes must identify whether they affect frontend, APIs, contracts, vendor integrations, worker logic, or release posture.
• Emergency fixes may be handled faster, but they still need a written summary before release closure.
• A design or legal page request does not silently authorize backend or chain behavior changes.

Client access should follow the minimum level needed to complete the engagement. Demo data, test credentials, and staging environments are preferred until production access is necessary.

The provider may refuse to work from unsafe credential delivery methods, shared personal accounts, or environments that mix demo and production values without clear separation.

• Secrets belong in environment variables or an approved secret manager.
• Production keys, private wallets, and x402 facilitator credentials must be rotated if they are exposed in the wrong place.
• Unsafe redirect targets, open public admin routes, and mis-scoped operator roles are treated as security issues, not minor UI defects.

The provider only needs enough client data to perform the agreed programming work. Sensitive operational information should be limited to what is required for debugging, testing, migration, or validation.

Logs, exports, and copied datasets should avoid real secrets and should not be kept longer than necessary for the engagement or for documented audit reasons.

• Payment truth, receipt evidence, and operator audit history should remain distinguishable in any data export or dashboard copy.
• Client approval is required before using real production records in demos, screenshots, or public case studies.
• If regulated or confidential data handling rules apply, those rules override any default workflow convenience.

Work is delivered in small, reviewable slices whenever possible. Each slice should identify what changed, how it was verified, and what remains blocked or intentionally deferred.

A delivery is considered review-ready when the provider has completed the agreed implementation, run the relevant checks, and described any known verification gaps in plain language.

• Typical verification includes linting, type checks, route tests, integration tests, and targeted manual review for the affected surfaces.
• Money-moving, auth, policy, worker, and release changes carry a higher verification bar than copy-only updates.
• Client acceptance should be given within the agreed review window or the delivery is treated as accepted except for written defects tied to the approved scope.

The provider will communicate material blockers, production risks, and missing dependencies as soon as they are known. Clear status updates are part of the service because silence creates delivery risk.

Support after launch should follow the support window or maintenance agreement defined in the applicable order, proposal, or statement of work.

• A blocker must identify the exact route, service, environment, or approval that is missing.
• Incident response priorities may be raised when the issue affects operator access, treasury controls, payment correlation, or production release safety.
• Requests that depend on third-party downtime, vendor API failures, or chain outages may need adjusted timelines.

Mandate402 may depend on third-party services such as hosted auth, database infrastructure, vendor APIs, x402 tooling, blockchain RPC providers, and oracle feeds. The provider can implement against those systems, but cannot guarantee their uptime or pricing.

When the solution touches Morph, x402 vendors, or other external infrastructure, the engagement should state which parts are under direct provider control and which parts are external dependencies.

• Third-party outages, network congestion, or breaking API changes may affect delivery dates or production behavior.
• The provider may recommend fallback plans, but fallback execution should never be presented as the default path if the product treats it as gated behavior.
• License, subscription, and infrastructure fees from third-party providers remain the client's responsibility unless the agreement says otherwise.