Ascension: operate, inspect and continue one project
Open Studio · Nova-Seed guide · MARK wallet · Engineering and acceptance
The project starts before an NFT exists. Keep its opportunity, exact work, seed, campaign, executor, results, assets and next mission together. Each cycle keeps its own commitments and permissions. A new mission does not erase the previous work or inherit its authority.
Deployment availability: the recorded October 11 Mainnet contracts permit inspection and eligible recovery. New exposure remains blocked, and this build has no qualified production replacement profile. Local qualification uses explicitly identified test assets and actors. Consult the 80-case evidence index for the historical requirement decisions and release readiness for how to verify the combined release. The existence of these controls is not a claim that a complete Mainnet lifecycle has been commissioned. The disposable worked example retains the tested two-cycle journey, exact signed records and locally decryptable synthetic recovery files.
First use
- Create or continue a project. Describe one useful objective and its current baseline. Identify the inputs, output, acceptance criteria and reuse rights. Local preparation needs no wallet or paid service.
- Prepare the exact seed. Add the committed jobs, compile the plan, encrypt it and verify local recovery. Keep the capsule passphrase separately from the recovery export. Never enter a wallet recovery phrase.
- Review what will be public. Publish only the intended encrypted capsule and reviewed public metadata. Verify retrieved bytes. Routed job descriptions become public even when the capsule is encrypted.
- Connect the appropriate actor. Select a wallet explicitly and inspect the exact deployment and current prerequisites. A namespace, admission or reviewer request can require another real actor's decision. Waiting for that actor is resumable; it is not completed admission or review.
- Mint, review, fund and activate. Each operation has its own preparation, review, confirmation and receipt. Minting sends zero ETH value apart from gas. It needs no invented token mint fee or ERC-20 mint approval. Funding requires its own bounded allowance and purchase. Activation ends funding-curve redemption.
- Seal richer work terms before routing. The runtime must retain the exact work, inputs, release, environment and MARK/seed/plan relationship before the job is posted. The future winner/job ID is unresolved.
- Assign and authorize genuine execution. Observe the actual routed job and auction winner, then obtain the actual controller's separate grant. Dispatch only the bound inputs to the supported installed executor.
- Inspect delivery, review and settlement. Compare exact output bytes with the committed acceptance criteria. The worker submits; the assigned reviewers decide. Reconcile the canonical settlement and amounts.
- Inspect what is yours. Separate money and obligations, reusable artifacts, and measured outcomes. Unknown costs or observations stay unknown. A returned deposit is not profit.
- Evaluate and choose the next mission. Compare a frozen candidate with its baseline, retain negative findings, and deliberately choose a version. A distinct next mission needs new work, fresh authorization, reviewed output and settlement. A changed title or reused receipt is not another mission.
The Nova-Seed guide details the existing creation, publication, wallet, review, funding and routing controls. The native adapter guide defines the exact preposting/assignment/delivery/settlement bindings; runtime installation is a separate one-time operator task. Do not export a job after settlement and present that export as evidence it was executed under prior authority.
Who acts next?
| Role | What that role may decide | What it does not acquire automatically |
|---|---|---|
| Project operator/business | Project scope and permitted business/campaign actions | Funder claims, validator votes or runtime control |
| Funder/lot holder | Its own permitted purchase, sale, transfer and claim | Business control, company equity or guaranteed returns |
| Worker | Bid, perform authorized work and submit its exact delivery | Acceptance of its own work or other workers' grants |
| Runtime host | Run installed bounded software within its actual permissions | Validator or spending authority because it supplies a computer |
| Runtime controller | Grant exact bounded execution through its trusted role | Permission to sign wallet transactions |
| Seed reviewer | Evidence-bound risk review under the current contract | Job acceptance, improvement adoption or spending approval |
| Assigned job reviewer | Accept/reject the exact contracted delivery | Automatic authority over seed review or successor selection |
| Adoption/spending authority | Its separately scoped version or spending decision | Every other role's permission |
Ascension Business, Agent and Validator names are respectively *.alpha.agi.eth,
*.alpha.agent.agi.eth and *.alpha.club.agi.eth. Registration, current ownership, admission and
eligibility are distinct. Funding-only participants follow the selected contract's actual admission rules.
Different addresses or processes do not establish independent beneficial control.
Connect work to a real executor
The supported path uses the repository's native SUCCESSOR runtime on the operator's own machine. Keep the installed release, source identity and environment with the record. A portable request is a handoff; it becomes execution evidence only when the installed runtime performs the task and returns verifiable run and artifact records. Inspect the actual run ID and status, not a decorative connected indicator.
After the native installation, start the existing private operator console:
alpha-agent --home ./agent-state serve
Open http://127.0.0.1:8765/ascension-studio. Enter the access token from the private
agent-state/api.token file in that local console; keep it out of the hosted Studio, recovery exports and
shared files. The token stays in the local page's memory. The console's setup view reports missing runtime
prerequisites. An authorized host operator first provisions the separately verified trust identities and
any optional private signer/role-token slots through the existing private installation process. The
first-install form then records reviewed actors, bounded policy and pinned read-only deployment settings.
It creates no keys or trust and refuses to overwrite an existing configuration.
Use the hosted Studio's exact work request file in the local console. If it needs a new work context, choose the installed deployment/role policy and actual seed in Pair a new work item, then review and confirm the exact bounded work. Pairing creates the proposed context; its companion obligations stay pending and it receives no execution grant or admission. Explicit preinstalled profiles remain supported.
Review and prepare the work, seal its terms before posting, and bind the actual assignment after the auction. The actual controller can either sign the downloaded request externally or use the installed local signer with their separate controller approval token. The ordinary API token cannot replace that approval. Signing the grant and starting the run are separate confirmations. Inspect and export the retained result. The configured acceptance owner then uses their own separate token or signed file to accept/reject the exact report. This does not replace on-chain committee review or make a payment. Import the observed closure for settlement verification and return its signed record to the project.
A distinct next work item uses a fresh confirmed pairing under the installed policy, a new assignment and new controller grant. No old cycle's permission is inherited. Keep controller/acceptance approval tokens only in the appropriate local approval form; never put them in a project, export or hosted Studio.
This file handoff works without a hosted page making a cross-origin call to the local machine. The local console keeps the existing authentication, Origin/Host checks and request limits. There is no generic shell, wallet-signing, unrestricted configuration replacement or arbitrary proxy interface. Both a raw imported request and its complete encoded POST must fit within 512 KiB. The form checks UTF-8 bytes, including JSON escaping and handoff fields, before sending; reduce the request if it exceeds that boundary. A rejected oversized request does not start work.
Before execution, the assignment must match the actual winning worker, chain/profile, market job, seed/plan index, richer terms, inputs, runtime release/environment and bounded expiry. The market observer and controller keys are trusted separately from the incoming file. Importing an embedded public key does not make it a trusted current controller. Controller approval remains separate from wallet consent.
The local baseline needs no paid model. Optional Computer Use uses a disposable Linux-container browser and its documented sites/actions/limits. It does not access a personal browser, wallet or arbitrary desktop. A live provider trial requires its own authorization and evidence; scripted actuator tests do not establish model capability. Unknown effects and failed cleanup require reconciliation.
Read the result without confusing the decisions
| Question | Evidence to inspect |
|---|---|
| Did the executor finish? | Actual run record, output bytes, resources where observed and cleanup outcome |
| Is this the promised delivery? | Exact result hash, input/term binding and the original acceptance criteria |
| Was the job accepted? | Actual committee decisions under the selected deployment's rules |
| Was the candidate better? | Frozen comparison and its PASS, FAIL, inconclusive, unauthorized or not-run outcome |
| Was money paid or refunded? | Canonical settlement, native amounts, rightful beneficiaries and reconciliation |
| May this artifact be reused? | Declared license/rights, provenance and the separate reuse/adoption decision |
| May another run begin? | Fresh work identity and current separately authorized runtime/spending permissions |
An accurate report saying a candidate failed can be accepted and paid. The failed candidate remains unadopted, and the previous baseline remains available. Missing review quorum follows the selected contract's refund/unlock rules; it is not proof the worker failed. Executor self-checks remain distinct from an independent real-world review.
Money, outputs and measured outcomes
The Value Reservoir has three views that must not be added together:
| View | Includes | Does not imply |
|---|---|---|
| Capital and obligations | Native wallet balances, reserve, escrow, stake, payouts, burns, pending transactions and claims by owner | Every contract balance belongs to the project operator |
| Reusable outputs | Exact accepted artifacts, rights, provenance, tests and negative findings | Ownership of every IP right or a cash valuation |
| Measured outcomes | Baseline, comparison method, quality, observed time/resources and supported costs | Guaranteed savings, realized revenue, profit or spendable capital |
Read the asset, chain, controlling account/contract, beneficial owner, observation block and restrictions for each amount. A claim and its backing custody represent one entitlement, not two assets. Shared-wallet funds cannot be allocated to several projects simultaneously. Local planning reservations are not chain locks. The current project model does not persist a shared allocation ledger across projects or devices; its proposal view alone cannot prove that another project has not reserved the same wallet funds. Keep those commitments visible and reconcile them with the controlling owner before a new funding decision. Burned tokens are not treasury income. Worker revenue is not automatically business revenue. ETH gas, token expenditure and any observed provider/storage charges remain separate. A missing price is unavailable.
In Value Reservoir, use Reconcile retained settlements with the separately pinned observer key. Studio rechecks original signed records against the selected deployment's finalized receipts and current terminal jobs. It shows each recipient's gross payout, burn and net amount, plus each refund's campaign custody. These are historical flows; refresh assets & obligations separately for current balances. After all lots are reclaimed, an old refund does not become a new asset. This view does not establish a complete account history, identify principal-return beneficiaries without their own receipts, or calculate profit. A missing receipt or changed canonical block makes reconciliation unavailable.
Known successful direct-reclaim receipts saved in the wallet journal are also rechecked against the original
cycle, selected deployment and finalized CapitalReturned event. The separate principal-return list names the
actual recipient, exact token amount, transaction and log index; it never adds these historical amounts to
current wallet balances or payout income. A zero-value observed return is zero; no known receipt remains unknown.
The journal is bounded and is only a lookup hint, so this does not establish complete account history.
Integrators may supply up to 256 explicit {cycleId, transactionHash} references through
readProjectLedger(..., {observerKey, principalTransactions}); those undergo the same live checks.
All-cycle gas, provider/storage charges, original cost basis, profit and shared fund reservations remain separate.
Continue the original plan only with its original unposted jobs, exact proofs, actual reserve and remaining time/reviewer capacity. Eligible job refunds return to that original campaign.
Fund a successor only with the rightful owner's unencumbered funds. If funds must be released from the original campaign, use its valid sale/closure/reclaim path and verify the claimant's proceeds first. Then review a separate approval and purchase for the next campaign. The business cannot sweep all lot holders' reserve into a new seed. Keep partial completion and unresolved transactions visible.
After opening the intended next campaign, use Propose reinvestment to enter a maximum amount, lot count, reason and retained obligations. Review current proposal checks the connected owner's current wallet balance and the destination quote. It sends nothing and reserves nothing. Continue to funding controls carries those inputs to the normal review, approval and purchase steps; each still needs a fresh wallet preparation and explicit confirmation. The proposal cannot spend another holder's claim.
Evaluate, then deliberately continue
Freeze the baseline artifact, candidate artifact/diff, task distribution, acceptance criteria and comparable resource budgets before evaluation. Use fresh or held-out inputs, and record where independence or input custody is limited. Keep quality, latency, resources, reliability, review effort and permissions separate. Missing dollar telemetry cannot demonstrate dollar savings; faster but incorrect work is not an unconditional win.
The initial built-in comparison uses the numerical workbench's trapezoid and Simpson methods on a distinct fresh polynomial or domain. It freezes common inputs, steps and an absolute-error tolerance, then retains the actual exact errors and observed runtime. These are operator-visible inputs, not an independently protected holdout. A result supports only that declared comparison; it does not prove general superiority, independence or dollar savings. Other candidate types need their own supported evaluator and evidence before an improvement claim.
In the local operator, select the retained baseline and Freeze comparison before this work runs. Execute the independently authorized fresh numerical work, then choose Evaluate the frozen comparison and download its signed report. Return that exact report to Studio with the separately retained observer identity. The comparison does not adopt a candidate automatically.
Choose adopt, reject/retain baseline, or hold only after inspecting the actual result and rights. A rejected proposal remains in history. Prepare a distinct mission using the explicitly chosen artifact on different inputs or independently justified fresh conditions. Bind the reused artifact and allowed use. The second cycle gets new plan/evidence, assignment, run, result, review and settlement identities.
The initial reuse path selects the accepted numerical report's actual calculation-input.json artifact.
After current result/settlement verification and your explicit source/license review, the next mission
inherits that recipe's integration bounds, step count and absolute tolerance and uses different polynomial
coefficients. The next run therefore consumes identified prior output and performs fresh work. This local
rights declaration does not establish an independent license audit or grant execution permission.
On-chain parent linkage requires the parent to exist in that same seed contract and be owned by the caller. Cross-deployment provenance stays an explicit off-chain relationship with full chain/contract/token identity. Neither form transmits the parent's risk review, passphrase, campaign control, grants or spending permission.
Recover the full project
Keep an export after meaningful progress, and keep original signed native records and a trusted checkpoint separately from the private runtime home. The old Nova-Seed Recovery Kit contains readable job specifications and wallet associations. Its original privacy warning still applies. The compatible encrypted-private project export is intended for sensitive project/terms/provenance; keep its passphrase separately and protect availability.
For host recovery, separately retain or deliberately reprovision the current operator configuration, trust, installed role keys and approval-token files through the administrator's private process. The existing native backup is not claimed to include all newly configurable signer/token paths. These secrets never belong in a public project export. Restoring historical results does not require making their old grants active again.
On a fresh browser or device:
- Import the exact supported export and verify/decrypt locally. Preserve original signed bytes and old cycles.
- Check the selected deployment and refresh current chain ownership, review, campaign, job and claim state.
- Reconcile every unresolved wallet intent using its original identity and known/replacement receipt.
- Authenticate native historical records against independently retained trust/checkpoints. Embedded keys explain provenance only; they cannot establish current authority.
- Inspect incomplete runs and uncertain effects. Obtain fresh authority where required, and continue only the valid next action. Restore must not sign, replay execution, reissue grants or adopt a candidate.
A lost response is not a failed transaction. Do not reseal, mint, route or purchase again merely because a page was closed. A browser lock coordinates its actual origin/profile; it does not coordinate another device. Local data deletion neither revokes external permission nor erases on-chain history.
When something needs attention
| Situation | Responsible actor / concrete next action | Evidence required before continuing |
|---|---|---|
| Wrong wallet/network or changed provider | Wallet owner reconnects/selects explicitly and prepares a fresh preview | Current actor/chain/profile, fresh simulation and explicit confirmation |
| Expired ENS/admission/review | Actual name owner, admission authority or reviewers resolve their prerequisite | Current verified eligibility or new review; legitimate exits remain available |
| Seed transferred | Current owner and original business inspect their separate rights | Fresh ownership, campaign control and review state; no assumed transfer of passphrase |
| Missing/changed storage | Storage operator retrieves exact original bytes or repairs their availability | Matching exact hashes; a new upload must not silently become a new package |
| Lost capsule passphrase | Owner checks separately retained authorized backups | Successful decryption of the original package; no invented reset or wallet-phrase request |
| Unknown mint, funding, route or claim | Signing wallet owner reconciles original sender/nonce/intent and known hashes | Canonical exact receipt or proven replacement/cancellation; no automatic retry |
| Disconnected or failed executor | Runtime controller inspects authenticated run state and dependencies | Exact request/run identity and current authority; absence of heartbeat is not acceptance |
| Unknown paid call or browser effect | Runtime controller reconciles external target and retained reservations | Recorded operator judgment; no blind replay or fictional zero cost |
| Failed runtime cleanup | Host operator isolates/quarantines and resolves the session | Verified cleanup or reviewed disposition before another effectful run |
| Missing job review quorum | Assigned reviewers/obligation operator inspect deadlines and permitted timeout path | Actual selected-contract state and refund/unlock accounting, not a worker-failure label |
| Rejected/slashed work | Worker/client inspect exact votes, result and selected-profile economics | Actual settlement, bond/payout/burn/refund deltas; no invented appeal or rescue |
| Refund or remaining campaign funds | Business collects eligible job refund; entitled holder uses valid exit/claim | Canonical collection/closure/reclaim and claimant balance; no reserve sweep |
| Reorganized/stale observation | Operator refreshes canonical chain/profile state | Invalidated evidence retained historically; phantom liquidity removed from allocation |
| Unsafe dependency/profile or frontend | Maintainer suspends new exposure under reviewed policy; operator tracks obligations | Exact replacement/rollback identity, retained recovery route and current legitimate exits |
An action after a deadline may itself move funds or slash collateral. Inspect the actual call before confirming it. A frontend stop or rollback cannot undo transactions or instantly pause immutable contracts.
Obligations when the browser is closed
The static site is not a background keeper. The project operator owns the obligation register: each open auction, delivery, review, admission/ENS expiry, pending transaction, unsettled job and unclaimed amount needs a named actor and next-check time. Retain these times with the project and use an independently operated reminder/monitoring service if continuous coverage is required. No such service is implied by closing Studio.
Before closing an active session, reconcile known transactions, export progress, record upcoming deadlines, and hand off any action requiring another person. At the next check, refresh the exact profile and chain state, inspect artifact availability/reviewer capacity, and prepare only the currently valid action. If nobody acts, the actual contract's deadline/recovery rules apply; automatic settlement is not promised.
Qualification before public operation
| Owner | Clearance evidence |
|---|---|
| Integration/release maintainer | Exact reviewed source, required CI, preserved workflows, genuine two-mission production-browser evidence and matching published assets |
| Security/integration reviewers | Resolved findings across wallet/ABI, crypto, profile, trust, accounting, recovery and browser isolation |
| Storage operator | Authorized real-account upload, independent retrieval, retained byte hashes and retention/cost arrangements |
| Wallet/accessibility testers | Actual declared extension/mobile/hardware and human keyboard/screen-reader/larger-text trials with versions and outcomes |
| Deployment/governance actors | Exact deployment/dependency/authority qualification, genuine role/admission prerequisites and bounded operation policy |
| Runtime/provider operator | Installed runtime/source/environment, independently pinned trust and real model/usage evidence only where claimed |
| Canary participants/approvers | Separate approved actors/actions/amounts/time; real lifecycle, continuation and reconciled receipts/obligations |
| Public launch authority | Explicit review of canary evidence and a distinct public-activation decision |
Français · suivre un projet jusqu'à la mission suivante
Commencez par un objectif précis, ses données autorisées et ses critères d'acceptation. Préparez le plan exact, chiffrez la capsule et vérifiez la récupération avant toute demande de signature. Conservez le mot de passe séparément; n'entrez jamais une phrase de récupération de portefeuille dans Studio.
Vérifiez le profil de déploiement, les rôles et l'acteur qui doit agir. La création du NFT, l'examen du seed, le financement, l'activation, l'attribution du travail et l'autorisation du contrôleur sont des étapes distinctes. Les conditions d'exécution sont scellées avant publication du travail. L'exécuteur doit produire un résultat réel, lié aux entrées et à l'autorisation exactes; un fichier exporté ou un message « terminé » ne suffit pas. Les contrôleurs, travailleurs et réviseurs gardent leurs permissions propres.
Inspectez séparément le résultat, l'acceptation, le verdict sur le candidat et le règlement. Un rapport exact concluant « FAIL » peut être accepté et payé sans adopter le candidat. Les remboursements de capital, les objets réutilisables et les bénéfices estimés ne deviennent pas automatiquement un profit disponible. Seul le détenteur légitime utilise sa créance ou ses fonds libres pour financer une nouvelle campagne.
Comparez le candidat à une référence figée, puis choisissez explicitement la version à utiliser. La mission suivante doit avoir de nouvelles entrées ou conditions justifiées, une nouvelle autorisation, un nouveau résultat vérifié et son propre règlement. Elle n'hérite ni des permissions ni de l'approbation du seed parent.
Après restauration, vérifiez les preuves, l'état actuel de la chaîne et les intentions encore incertaines. Ne renvoyez pas une transaction et ne relancez pas un effet externe à l'aveugle. La page ne surveille pas les échéances lorsqu'elle est fermée: désignez les responsables et conservez les prochaines vérifications. L'archive Mainnet du 11 octobre reste limitée à l'inspection et aux opérations de récupération réellement permises. Les essais locaux ne constituent ni une autorisation publique ni une qualification Mainnet.