The important boundaries are product boundaries: AI output review, evidence limits, payment authority, privacy, and acceptable use.
Access, buyer responsibility, output reliance limits, and ReArch service boundaries.
Privacy policyHow case stories, evidence, account data, billing data, and package records are handled.
Billing policyQuote authorization, payment processor limits, refunds, chargebacks, and blocked runs.
AI output reviewHuman-review duties and limits on relying on generated architecture artifacts.
SecurityAuthentication, custody, evidence handling, payment truth, and vulnerability reporting.
Acceptable useMisuse boundaries for submitted material, generated packages, and system access.
These product terms define the ReArch buyer workflow, payment boundary, evidence limits, and output-review duties.
ReArch provides case understanding, architecture, blueprint, execution planning, and session workflow support for professional app-building work.
You are responsible for reviewing generated outputs before relying on them, submitting only material you have the right to use, and deciding whether a package is suitable for your project.
ReArch may block, retry, pause, or fail a run when payment, evidence, provider, abuse, or custody checks cannot be completed safely.
ReArch may process case stories, pasted evidence, uploaded artifacts, account identifiers, billing metadata, run records, and package records to operate the service.
Submitted case material is used to understand the case, produce the authorized package, maintain custody, support resume/recovery, and respond to support or safety issues.
Payment card details should be handled by the payment processor. ReArch stores only the billing and authorization facts needed for service operation and audit.
A payable quote appears only after the case basis is confirmed and priced by the backend contract.
When checkout is mocked or staged, ReArch must say so. In live payment mode, run authority comes only from server-verified payment provider events.
Refund, chargeback, wrong-amount, unknown-session, or reversed-payment states may block run continuation or package delivery until the billing truth is resolved.
ReArch outputs are decision-support and build-support materials. They are not guarantees of production readiness, commercial success, legal compliance, or bug-free implementation.
The system must preserve evidence limits. Where submitted material is thin, missing, contradictory, or reported-only, package outputs should label those limits instead of pretending certainty.
You should independently review architecture, blueprint, execution steps, and prompts before applying them to code, customers, finances, safety-sensitive work, or regulated environments.
ReArch is designed around custody: buyer records, evidence, quote authority, run records, package records, and downloads should remain isolated to the authorized buyer/workspace.
The service should not expose raw backend IDs, secrets, payment signatures, provider errors, or package internals in public buyer-facing pages.
Security issues should be reported privately so the service can investigate and repair before public disclosure.
Do not use ReArch to submit material you do not have permission to use, bypass access controls, generate malware, conceal abuse, or materially assist unlawful activity.
Do not use generated packages as a substitute for qualified professional review where legal, financial, medical, safety, or regulated decisions are involved.
ReArch may reject, block, suspend, or remove work when submitted material or requested use appears unsafe, unauthorized, abusive, or outside the service boundary.
The package is decision and build support. It does not guarantee commercial success, bug-free implementation, or production readiness.
Where code, screenshots, audits, or repo artifacts are missing, ReArch must label the limit instead of pretending certainty.
