Protected Flywheel operating slice / Parcours opérationnel protégé

English

This implementation extends the existing signed Journal, TransformationLibrary, native operator and API. The public Flywheel remains a free simulation and preparation experience. Opening it performs no provider call, wallet signature, transaction, customer contact or protected-service request.

The first supported retained implementation is the existing closed source-evidence selector: a typed public document, a bounded selection program and an immutable acceptance charter produce an attributable source-clause summary. Imported Python, shell, instructions, dependencies and dynamic imports are not supported capsule contents. This finite public algorithm family does not itself establish Alpha over competent current models and ordinary tools. A correctly rejected candidate is an expected outcome.

Current operating map

Stage	Implemented boundary	Qualification still required
Explore	Existing public deterministic commercial simulation	No actual sales or model-quality inference
Prepare	Existing Alpha project, history, exports, recovery and handoffs	Exact beneficiary, rights, acceptance, resources and actions
Execute	Opt-in native provider connector; one signed, bounded attempt; no implicit retry	Approved endpoint, exact served model ID, requested versus served reasoning, tools, quota, billing and budget
Learn	Accepted originating Journal record, complete A costs, frozen encrypted candidate, prospective matched plan, separate evidence, assessment, validation and admission	Actual frontier paired runs, independently informative acceptance and complete B costs
Reuse	Resource-specific wallet proof; fresh two-reader ENSv1 checks; closed local execution; durable attempt, failures and unknown cost	A different eligible name and wallet, fresh accepted work, reconciled all-resource costs and current matched Beta
Requalify	Changed Beta/policy removes active pointers; finite expiry; recursive dependency checks; terminal revocation	Fresh affected evidence; supersession is not automatic economic improvement

No deployment-specific live ENS qualification, actual frontier trial, paid customer receipt, production capsule deployment or measured real peer advantage is established by the conformance fixtures. The native status endpoint reports this limit. Synthetic test wallets, code pins, receipts, prices, budgets and acceptance statements are fictional; their cryptographic checks execute real software.

Native operation and service boundary

The existing operator adds:

alpha-agent --home /private/agent serve --flywheel-deployment /operator/protected-deployment.json
alpha-agent --home /private/agent flywheel --deployment /operator/protected-deployment.json --output /private/status.json status

The server still binds to numeric loopback. Existing operator endpoints retain their bearer-token protection, request limits and security headers. Exposing a service through an approved HTTPS proxy, including host, transport, request-rate, storage and monitoring configuration, is a separate provisioning step. The public website never receives an operator token, model credential or encryption key.

A deployment file must contain exactly schema_name=protected-flywheel-deployment/v1, service, producer, trust_path, checkpoint_path, readers, ens_pins, keys and active_key. The keys mapping identifies private 32-byte AES-256 key files; it does not contain key bytes. Two separately approved Ethereum-mainnet RPC providers with different hostnames and independently checked Registry, Wrapper and Registrar SHA-256 implementation pins are mandatory. Existing read-only RPC transport is reused; it cannot broadcast. No default endpoint, model, code pin, credential or trusted signer is invented. Deployment and trust files are private regular files. The running service binds their exact loaded bytes and the key inventory; changes, loss or insecure permissions refuse protected work and accounting until restart/requalification. Runtime configuration is checked against disk and the Journal control record, including edits made by another process. Health reports a restart/recovery requirement when these checks fail.

Commands candidate, plan, evidence, validate, admit, revoke, rotate-key, reuse-acceptance and account consume separately signed, journal-bound decisions. model-run additionally requires a controller-signed model permit with the exact request/configuration, requested reasoning, no-external-tools manifest, quota evidence, finite expiry and charge allowance. This first connector uses the existing JSON-completion transport. Responses/tool/computer-use executors require their separately approved connector and qualification. An available subscription does not establish an API entitlement. Missing access refuses before a call.

Reasoning mode (standard/pro) and reasoning effort are separate signed fields in permits, plans and receipts. This transport supports standard-mode JSON completion only; Pro refuses before consuming a permit or charging an attempt. The no-tool payload uses reasoning_effort and max_completion_tokens. External approved Responses executors may attest matched Pro runs, but none is provisioned or claimed here. Actual served mode/effort, account access, quota and billing remain unverified until qualified on the approved account. Official profiles checked 2026-10-27 identify gpt-6-astra and gpt-6.1-terra; an alias or public price is not an account entitlement.

B extraction binds the exact completed native Research mission revision and includes its request, accepted result and review in the provider context. A development binds an open native Research mission; C remains separately authorized investment. The closed origin scope avoids replaying arbitrary host-code work during candidate verification. A fabricated acceptance flag or altered result cannot establish a completed origin.

The protected API exposes /api/flywheel/status, /challenge, an authenticated /catalog and per-capsule /manifest and /invoke beneath /api/flywheel. Without provisioned resources it returns 503 for protected work. There is no plaintext capsule-download endpoint. Manifest discovery and invocation each require their own one-time, two-minute, service/purpose/resource/request-bound EIP-191 challenge. Challenge issuance is bounded globally and per wallet. No session cookie or browser-supplied name grants eligibility.

Supported authority is deliberately narrow: an exact lowercase ASCII direct label under agent.agi.eth, EOA wallet control, current ENSv1 Registry authority or NameWrapper ownership, live parent/wrapped expiry and unexpired agi.eth registration. Code pins, current block age, canonical block hash, reader agreement and ownership are checked at every resource crossing. Delegations, contract-wallet signatures, internationalized labels, CCIP/offchain names and ENSv2 are unsupported; their qualification cannot be inferred from a fixture. Approved providers and namespace protocol selection remain trust dependencies. Identity reads occur outside the Journal write lock, with four concurrent checks, a total deadline, two-second RPC timeouts and a short-lived server-only authorization checked again during commit. Both readers must report the same current tip before and after verification. Failure or disagreement refuses access; an operator stop is not held behind network reads. The concrete RPC transport propagates the remaining total deadline through connection, headers and asynchronous streamed body reads; cancellation closes a trickling response rather than waiting for its end. No existing Jobs club.agi.eth validator role, contract, currency route or settlement rule changes.

Evidence, economics and admission

A records all resources for accepted delivery, including learning during that job. B records only extra extraction, generalization, testing, retention, distribution, revalidation and reuse. C records separately authorized extra investment. An activity ID cannot be charged into two buckets. Every paired evaluation invocation must have its exact signed receipt charged once in the frozen B record. Zero-cost categories require an explicit signer attestation; unknown amounts remain unknown. All nine resource categories must be reconciled before a delivery, retention or reuse cost record can be sealed. Seals are bucket-specific: completing A cannot complete B or C, and completing B cannot complete A. Delivery profit remains independently reportable when A is complete and optional B or C remains incomplete.

Offers, invoices and pending payment create no collected revenue. Capital is separate from revenue. Amounts are integer USD micro-units, separate from AGIALPHA utility or token transfers. Reports distinguish complete-cost profit, cash, obligations, reserve and available funds. Unknown costs prevent complete-cost profit or available-funds claims. Collection records are attributed accounting attestations with evidence commitments; no bank verification or real collection is claimed here. The signed account action payment records a later payment against an existing known activity with a unique payment_id, activity_id, positive amount_micro_usd and allocated evidence_digest. Partial payments reduce cash and outstanding obligations equally, preserving accrual, A/B/C ownership and completeness seals. Overpayment, duplicate allocation evidence and unknown liabilities refuse; repeated identical commands are idempotent. This records an attributed payment attestation and never transfers funds. Accounting replay protection and full payment attestations also use durable individual Journal records. The cost working record keeps at most 128 operation fingerprints and 32 payment attestations; eviction cannot permit a repeated command or allocated payment evidence. Reserved byte/node capacity covers each unknown charge's bounded reconciliation, each missing resource category, completeness seals and partial payment summaries. Both provider and selector attempts must persist those reserves before execution. The two-megabyte/100,000-node cost record remains finite: new intake refuses when reconciliation headroom is exhausted. This slice does not provide unlimited accounting storage or automatic archival of charges. Incoming funding evidence can credit cash only once across capital and collected revenue. With unknown costs, total obligations and available funds remain unknown; known_obligations reports only reconciled liabilities. Prepayments reduce cash without creating a negative fictitious liability.

Only a completed native Research mission, with a verified exact result, approved review and complete A costs, can produce a candidate. The original agent's wallet must already have the existing wallet-control binding and fresh eligible ENS authority. A frozen plan names current Beta/policy, the same frontier model/reasoning/tools/resource rules, the recipient's existing capability commitment, excluded delivery inputs, fresh inputs, a prospective reuse count, uncertainty basis and the complete B cost record. Executions must follow freeze. Configured execution custodians attest response/output/usage/billing identities; acceptance uses distinct configured keys and separately informative tests. Signatures bind attestations; they do not establish their truth or organizational independence. Whole-mission identity is separate from source identity. Retention derives canonical SourceDocument projections and ti-source commitments from the actual accepted Research sources. The candidate command returns the required origin exclusions. Plans bind the exact fresh source documents and their ti-source digests, and must include all originating source commitments. Normalized source URI (without query) and text fingerprints prevent simple title, weight or claim-ID changes from disguising previously exposed origin/evaluation material. This conservative policy requires distinct source identities; it does not prove semantic novelty or independently authenticate a supplied public URL.

The plan also binds an execution-environment digest over installed source bytes, dependency versions, runtime configuration, service and identity-reader policy. A material change requires restart and explicit requalification; stale assessment, validation, admission, discovery and invocation refuse. Evaluation input commitments remain exposed after model changes and cannot be reused as fresh cases. Reuse's matched Beta receipt must also bind the requesting agent's declared existing capabilities.

Correctness and economic value are separate. The supported lower net saving per use cannot exceed the least observed paired saving. Its prospective reuse value must exceed already incurred B plus declared remaining retention costs. A is never charged again. This conservative finite rule is not a calibrated general demand forecast, statistical confidence procedure or automatic proof of transferable value. Insufficient or negative evidence rejects; failures remain in audit history, outside active admissions.

Validation and admission require separate configured roles and current bindings. Local structural-library promotion does not touch protected admissions. Imported state cannot install signers, keys or executors. An invocation produces an executed receipt, not a successful-reuse claim. The latter requires independent acceptance, a fresh current Beta receipt and all-resource cost reconciliation. Attributable additional value may be negative; accepting useful work does not imply a positive economic advantage. Every eligible network agent, including the originating agent, can discover and invoke an admitted capability within its supported scope. successful_reuse records accepted, reconciled work. successful_peer_reuse additionally requires a different authenticated name and wallet; origin-agent work or a second name on its wallet cannot establish that peer claim. Availability is not restricted to the agent used for the qualification exercise. Every actual Beta comparison is itself a chargeable invocation, charged exactly once to B before accepting reuse. Its execution must follow the fresh request commitment. Reports show both operating savings before comparison overhead and additional value after all current costs. A useful accepted reuse can have negative net value during qualification; omitting the baseline bill cannot manufacture a positive return. Cost-record eligibility is checked before execution. The challenge, invocation reservation and unknown cost are committed with the independent high-water mark before computation. An interruption remains executing-or-uncertain, blocks implicit retries and requires explicit cost/recovery reconciliation. Computation runs outside the write lock and observes stop requests. Historical evaluation inputs remain ineligible as fresh reuse even after a new plan, model change or rollback. Pending reuse acceptance must still match its exact qualification plan, Beta, policy and execution environment. Requalification or rollback cannot turn an older pending execution into current qualified reuse. Dependency verification uses iterative cycle detection and checks each shared dependency once per traversal. Dependency and whole-catalog verification have a one-second budget and fail without partial authorization or catalog disclosure; deployment sizing must qualify these operating limits.

Storage, keys, recovery and revocation

The protected branch lives inside the existing TransformationLibrary journal record. Public manifests remain separate from AES-GCM encrypted closed-program bytes. AAD binds service, journal and exact versioned manifest. Historical signed Journal snapshots preserve ciphertext and audit history. Existing private backups preserve that history; they contain the runtime identity key and remain private. Encryption keys are separately provisioned and excluded from those backups, bundles, logs and public pages.

Invocation requests and full receipts use separate versioned records in that same Journal. The shared working record retains every uncertain attempt and only 32 completed receipt references; eviction never removes the durable request, result, cost obligation or replay protection. Signed operations are also durable individual records, with bounded working caches. The native flywheel receipt MISSION_ID command exports a private operator receipt. Inputs are limited to 250,000 canonical bytes and full invocation records to 1,000,000. Oversized results become durable failed attempts with unresolved billing, not lost completions or successful reuse.

Every writer of the shared library preserves byte and JSON-node reserves before accepting new work. These include completion space and 25,000 bytes per revocable entry, covering a maximum-length Unicode reason. The existing two-megabyte, 100,000-node journal-record limits remain unchanged. Capacity exhaustion refuses new work before execution. A signed controller can archive a revoked/rejected entry into immutable encrypted Journal history; its terminal tombstone still prevents reactivation. This bounded slice retains the 128 candidate-identity limit; archival does not promise unlimited admissions or storage.

Existing v1.45 local structural records require no migration. An unreleased protected-storage prototype cannot silently become qualified storage. With the runtime paused, an exact-state signed controller flywheel migrate operation preserves the original prototype records, retires its candidates, and starts unconfigured current storage. Missing original invocation inputs remain explicitly unknown; historical receipts cannot be relabeled qualified reuse. flywheel archive and flywheel migrate require signed records through the existing native operator, never public-page actions.

The service owner must designate key custody, encrypted independent backup, rotation and recovery. Rotation reencrypts current records under a separately provisioned active key. Historical backups still require historical keys; removing an old key does not rewrite immutable history. Loss of necessary keys fails closed. No credentials or production keys are created by loading a capsule or deployment file.

A separately provisioned DurableCheckpoint must live outside portable runtime recovery state, preferably on independently retained durable custody. Every protected state mutation, accounting mutation, model permit consumption and successful resource crossing advances its monotonic high-water record before local commit. A crash between those commits may require explicit recovery; it refuses rather than accepting an older journal. Restoring an old backup cannot silently resurrect a revocation while current checkpoint custody is retained. A file on the same host is not independent remote durability, and rolling back both stores defeats that protection. The paid-attempt high-water mark is committed before the provider request. An older portable backup cannot reuse its permit while that custody is retained. Unknown billing remains an obligation requiring reconciliation.

Access is reconsidered at discovery and invocation, including dependencies and revoked configured signers. Changed models/policies require fresh evidence; terminal revocation cannot be promoted again. A new version is necessary for a revoked method. Controlled execution limits direct export; observable outputs may reveal behavior, especially for this small public selector family. Disclosed plaintext and learned behavior cannot be clawed back. There is no permanent-scarcity or accumulating-moat claim.

Approval needed for qualified live completion

The independent implementation can be reviewed and tested without provisioning production authority. Actual qualification requires the operator's approved service origin/host and durable storage; independently provisioned keys, trusted role registry and checkpoint custody; two approved RPC readers and real code pins; approved frontier executor/model configuration with a specific finite spend allowance and quota/billing evidence; and two eligible owner-controlled agent wallets signing fresh challenges. No private key or seed phrase should be provided to this application or in a repository.

Français

Cette implémentation prolonge le Journal signé, la TransformationLibrary, l’opérateur et l’API existants. Le Flywheel public reste une simulation gratuite et un parcours de préparation. Son ouverture ne déclenche ni modèle, signature, transaction, contact client ou requête au service protégé.

La première implémentation conservée utilise le sélecteur fermé de preuves documentaires existant : document public typé, programme borné et charte d’acceptation immuable produisent un résumé traçable. Les capsules n’acceptent ni Python, shell, instructions arbitraires, dépendances ni imports dynamiques. Cette petite famille publique d’algorithmes ne démontre pas, à elle seule, un Alpha face aux modèles frontière et outils ordinaires compétents. Un rejet justifié constitue un résultat attendu.

Étape	Frontière implémentée	Qualification restante
Explorer	Simulation commerciale déterministe publique existante	Aucune vente ni qualité réelle de modèle déduite
Préparer	Projet Alpha, historique, exports, reprise et transmissions existants	Bénéficiaire, droits, critères, ressources et actions exacts
Exécuter	Connecteur natif facultatif ; tentative unique signée, bornée, sans reprise implicite	Accès approuvé, modèle réellement servi, raisonnement demandé/servi, outils, quota, facturation et budget
Apprendre	Mission d’origine acceptée, coûts A complets, candidate chiffrée figée, plan prospectif apparié, preuves, évaluation, validation et admission distinctes	Exécutions frontière réelles, acceptation informative indépendante et coûts B complets
Réutiliser	Preuve de portefeuille propre à la ressource, ENSv1 frais auprès de deux fournisseurs, exécution fermée et historique durable	Nom ET portefeuille différents, tâche nouvelle acceptée, coûts complets et Beta actuel apparié
Requalifier	Retrait des pointeurs actifs après changement Beta/politique, expiration, dépendances récursives et révocation terminale	Nouvelles preuves affectées ; aucune amélioration économique automatique

Les tests de conformité ne qualifient ni ENS réel, ni modèle frontière réel, ni encaissement client, ni déploiement de production, ni avantage réel d’un autre agent. Portefeuilles, contrats, reçus, prix, budgets et acceptations des tests sont fictifs ; les vérifications cryptographiques exécutent du vrai logiciel.

L’opérateur existant accepte serve --flywheel-deployment et flywheel avec --deployment et --output. Le serveur reste lié à l’interface locale numérique. Les protections existantes des routes opérateur, tailles de requêtes et en-têtes demeurent. Un proxy HTTPS, ses hôtes, limites, stockage et surveillance exigent un provisionnement approuvé distinct. Aucun jeton opérateur, secret modèle ou clé de chiffrement n’entre dans le site public.

Le fichier de déploiement contient exactement schema_name=protected-flywheel-deployment/v1, service, producer, trust_path, checkpoint_path, readers, ens_pins, keys et active_key. keys référence des fichiers privés de 32 octets, sans contenir leurs clés. Deux fournisseurs RPC Ethereum principal approuvés, aux hôtes distincts, et les empreintes SHA-256 vérifiées du Registry, Wrapper et Registrar sont obligatoires. Le transport RPC existant reste en lecture seule. Aucun fournisseur, modèle, tarif, secret, signataire ou empreinte fictive n’est choisi par défaut. Déploiement et registre de confiance sont des fichiers privés ordinaires. Le service lie leurs octets chargés et l’inventaire de clés ; modification, perte ou permissions trop larges bloquent accès et comptabilité jusqu’au redémarrage et à la requalification. La configuration est comparée au disque et au contrôle du Journal, y compris après modification dans un autre processus. L’état signale alors une reprise requise.

Les décisions candidate, plan, evidence, validate, admit, revoke, rotate-key, reuse-acceptance et account exigent des signatures distinctes liées au Journal. model-run exige en plus un permis du contrôleur : requête/configuration exactes, raisonnement demandé, manifeste sans outils externes, preuve de quota, expiration et allocation bornée. Ce premier connecteur utilise le transport JSON-completion existant. Les exécuteurs Responses, outils et ordinateur demandent leur connecteur approuvé et leur qualification. Un abonnement ne prouve aucun droit API. L’absence d’accès bloque avant l’appel ; une réponse perdue reste une tentative incertaine facturable et ne déclenche aucune reprise automatique.

Mode de raisonnement (standard/pro) et effort sont des champs signés distincts dans permis, plans et reçus. Ce transport ne prend en charge que JSON en mode standard ; Pro bloque avant consommation du permis ou facturation d’une tentative. La requête sans outils emploie reasoning_effort et max_completion_tokens. Un exécuteur Responses externe approuvé peut attester des exécutions Pro appariées ; aucun n’est provisionné ou revendiqué ici. Mode/effort servis, accès du compte, quota et facturation restent à qualifier sur le compte approuvé. Les profils officiels vérifiés le 2026-10-27 identifient gpt-6-astra et gpt-6.1-terra ; ni alias ni prix public ne constitue un droit d’accès du compte.

L’extraction B lie la révision exacte d’une mission Research native terminée et transmet requête, résultat accepté et revue au fournisseur. Le développement A lie une mission Research native ouverte ; C reste un investissement autorisé séparément. Cette portée fermée évite de réexécuter du code hôte arbitraire pendant la vérification. Un simple drapeau d’acceptation ou résultat altéré ne crée aucune origine terminée.

L’API ajoute /api/flywheel/status, /challenge et un /catalog authentifié, ainsi que /manifest et /invoke propres à chaque capsule. Sans ressources provisionnées, le travail protégé retourne 503. Aucune route ne télécharge la capsule en clair. Découverte et invocation exigent chacune un défi EIP-191 unique de deux minutes, lié au service, à la finalité, à la ressource et à la requête. L’émission est bornée globalement et par portefeuille. Un nom saisi ou une session de navigateur ne crée aucune admissibilité.

La politique couvre seulement un libellé ASCII minuscule directement sous agent.agi.eth, un portefeuille EOA, l’autorité ENSv1 actuelle du Registry ou du NameWrapper, les expirations des parents enveloppés et l’enregistrement agi.eth non expiré. Empreintes de code, âge du bloc, hachage canonique, accord des deux lecteurs et propriété sont revérifiés à chaque accès. Délégations, portefeuilles contrats, noms internationalisés, CCIP/hors chaîne et ENSv2 ne sont pas pris en charge. Les fournisseurs approuvés et le choix du protocole de l’espace de noms restent des dépendances de confiance. Les lectures d’identité restent hors du verrou d’écriture du Journal : quatre contrôles simultanés, délai total, délai RPC de deux secondes et autorisation interne brève revérifiée à la validation. Les lecteurs doivent annoncer le même sommet courant avant et après les contrôles. Échec ou désaccord bloquent l’accès ; les lectures réseau ne bloquent pas un arrêt de l’opérateur. Le transport RPC propage le délai total restant à la connexion, aux en-têtes et à la lecture asynchrone du corps. L’annulation ferme une réponse qui distille ses octets, sans attendre sa fin. Les rôles Jobs club.agi.eth, contrats, devises et règlements restent inchangés.

A couvre la livraison acceptée, apprentissage pendant ce travail compris. B ne couvre que les coûts supplémentaires d’extraction, généralisation, tests, conservation, distribution, revalidation et réutilisation. C couvre l’investissement supplémentaire séparément autorisé. Un identifiant d’activité ne peut être facturé dans deux catégories. Chaque invocation d’évaluation appariée doit être liée à son reçu exact et facturée une seule fois dans B. Une catégorie à zéro nécessite une attestation explicite ; un montant inconnu reste inconnu. Les neuf catégories de ressources doivent être rapprochées avant clôture des coûts. Les clôtures sont propres à A, B ou C : aucune ne peut clôturer l’autre. Le profit de livraison reste calculable lorsque A est complet, même si B ou C facultatif reste incomplet.

Offre, facture et paiement en attente ne créent aucun revenu encaissé. Le capital reste distinct. Les montants sont des micro-unités USD entières, séparées d’AGIALPHA et des mouvements de jetons. Les rapports distinguent profit à coûts complets, trésorerie, obligations, réserve et fonds disponibles. Un coût inconnu bloque les affirmations de profit complet et de fonds disponibles. Les encaissements sont des attestations comptables attribuées, liées à des engagements de preuve ; aucune vérification bancaire ou recette réelle n’est établie ici. L’action comptable signée payment enregistre un paiement ultérieur d’une activité connue : payment_id unique, activity_id, amount_micro_usd positif et evidence_digest d’allocation. Un paiement partiel réduit trésorerie et obligations du même montant sans modifier charge, catégorie A/B/C ou clôture. Surpaiement, preuve d’allocation répétée et dette inconnue bloquent ; une commande identique répétée reste idempotente. Cette attestation de paiement n’effectue aucun transfert de fonds. La protection contre les répétitions comptables et les attestations de paiement complètes occupent aussi des objets durables individuels du Journal. Le registre de travail garde au plus 128 empreintes d’opération et 32 attestations de paiement ; une éviction n’autorise aucune répétition de commande ou preuve allouée. Les réserves d’octets/nœuds couvrent le rapprochement borné de chaque coût inconnu, les catégories de ressources manquantes, les clôtures et les résumés de paiements partiels. Fournisseur et sélecteur doivent enregistrer ces réserves avant toute exécution. Le registre comptable reste limité à deux mégaoctets et 100 000 nœuds : une réserve de rapprochement insuffisante bloque le nouveau travail. Cette tranche n’offre ni stockage comptable illimité, ni archivage automatique des charges. Une preuve de fonds entrants ne peut créditer la trésorerie qu’une fois entre capital et revenu encaissé. Avec des coûts inconnus, obligations totales et fonds disponibles restent inconnus ; known_obligations ne rapporte que les dettes rapprochées. Une avance réduit la trésorerie sans créer une dette négative fictive.

Une candidate exige une mission Research native terminée, son résultat exact vérifié, une revue approuvée et ses coûts A complets. Le portefeuille de l’agent d’origine doit être déjà prouvé par la liaison existante et disposer d’une autorité ENS admissible actuelle. Le plan figé nomme Beta/politique courants, modèle frontière, raisonnement, outils et règles de ressources identiques, capacités du destinataire, entrées d’origine exclues, entrées nouvelles, horizon prospectif, incertitude et registre B complet. Les exécutions suivent le gel. Des dépositaires configurés attestent réponses, résultats, usage et facturation. L’acceptation utilise des clés distinctes et des tests indépendamment informatifs. Une signature lie une attestation sans établir sa vérité ou son indépendance organisationnelle. Identité de mission et de source restent distinctes. La conservation dérive des SourceDocument canoniques et engagements ti-source depuis les sources Research réellement acceptées. La commande candidate retourne les exclusions requises. Le plan lie les documents nouveaux exacts et leurs empreintes ; toutes les sources d’origine doivent être exclues. URI normalisée sans requête et empreinte du texte empêchent de masquer un ancien matériau par changement de titre, poids ou identifiant. Cette politique prudente exige des sources distinctes ; elle ne prouve ni nouveauté sémantique ni authenticité indépendante d’une URL fournie.

Le plan lie aussi l’empreinte de l’environnement : sources installées, versions des dépendances, configuration, service et politique des lecteurs d’identité. Un changement impose redémarrage et requalification explicite ; évaluation, validation, admission, découverte et invocation périmées bloquent. Les entrées d’évaluation déjà exposées ne redeviennent pas nouvelles après changement de modèle. Le reçu Beta de réutilisation lie aussi les capacités existantes déclarées par l’agent demandeur.

La correction et la valeur économique restent distinctes. La borne prudente d’économie nette par usage ne peut dépasser la moindre économie appariée observée. Sa valeur prospective doit excéder B déjà engagé et les coûts futurs déclarés ; A n’est jamais refacturé. Cette règle finie ne constitue ni prévision générale de demande, ni procédure statistique calibrée, ni preuve automatique de transférabilité. Une preuve négative ou insuffisante produit un rejet conservé dans l’audit, hors admissions actives.

Validation et admission exigent des rôles distincts et des liaisons courantes. La promotion locale structurelle ne touche pas aux admissions protégées. Un import n’installe ni signataire, clé ou exécuteur. Une invocation crée un reçu d’exécution, sans revendiquer une réutilisation réussie. Celle-ci demande acceptation indépendante, reçu Beta actuel sur la tâche nouvelle et rapprochement de tous les coûts. La valeur supplémentaire peut être négative : une tâche utile acceptée ne prouve pas un avantage économique. Chaque agent du réseau admissible, y compris l’agent d’origine, peut découvrir et invoquer une capacité admise dans sa portée. successful_reuse désigne un travail accepté et rapproché ; successful_peer_reuse exige en plus un nom authentifié ET un portefeuille différents. Le travail de l’origine ou un autre nom sur son portefeuille ne prouve aucune réutilisation par un pair. L’accès ne se limite pas à l’agent du test de qualification. Chaque comparaison Beta réellement exécutée constitue aussi une invocation facturable, comptabilisée une fois dans B avant acceptation de la réutilisation. Elle suit l’engagement de la nouvelle requête. Les rapports distinguent économie opérationnelle avant comparaison et valeur supplémentaire après tous les coûts. Une réutilisation utile acceptée peut avoir une valeur nette négative pendant qualification ; omettre la facture Beta ne peut créer un rendement positif. L’admissibilité comptable précède l’exécution. Défi consommé, réservation et coût inconnu sont validés avec le seuil indépendant avant calcul. Une interruption reste executing-or-uncertain, bloque les reprises implicites et exige rapprochement explicite des coûts et de la reprise. Le calcul reste hors du verrou d’écriture et observe les arrêts. Une entrée d’évaluation historique ne devient pas une nouvelle tâche de réutilisation après changement de plan, modèle ou retour à un ancien modèle. L’acceptation en attente doit encore correspondre au plan exact de qualification, à Beta, à la politique et à l’environnement. Requalification ou retour arrière ne transforme pas une ancienne exécution en réutilisation actuellement qualifiée. La vérification itérative détecte les cycles et contrôle une seule fois chaque dépendance partagée par parcours. Parcours de dépendances et catalogue complet ont un budget d’une seconde : expiration sans autorisation ou divulgation partielle. Le dimensionnement du déploiement doit qualifier ces limites.

La branche protégée reste dans le Journal de la TransformationLibrary. Les manifestes publics sont distincts des programmes chiffrés AES-GCM ; les données associées lient service, Journal et manifeste versionné. L’historique signé et les sauvegardes privées existantes conservent chiffrement et audit. Ces sauvegardes contiennent la clé d’identité du runtime et doivent rester privées. Les clés de chiffrement sont provisionnées séparément et exclues des sauvegardes, bundles, journaux et pages publics.

Requêtes d’invocation et reçus complets occupent des objets versionnés distincts dans ce même Journal. Le registre de travail garde toutes les tentatives incertaines et seulement 32 références terminées ; une éviction ne supprime ni requête durable, résultat, obligation ou protection contre la répétition. Les opérations signées sont également des objets durables, avec caches bornés. La commande native flywheel receipt MISSION_ID exporte un reçu privé pour l’opérateur. Limites : 250 000 octets canoniques en entrée, 1 000 000 pour l’objet complet. Une sortie excessive devient un échec durable avec facturation non rapprochée, jamais une fin perdue ou une réutilisation réussie.

Chaque écriture dans la bibliothèque partagée préserve des réserves d’octets et de nœuds JSON avant d’accepter du travail. Elles couvrent la fin d’exécution et 25 000 octets par entrée révocable, y compris une raison Unicode de longueur maximale. Les limites existantes de deux mégaoctets et 100 000 nœuds par objet restent inchangées. Une capacité insuffisante bloque le nouveau travail avant exécution. Le contrôleur peut archiver une entrée révoquée/rejetée dans l’historique chiffré immuable ; sa marque terminale empêche toute réactivation. Cette tranche bornée conserve la limite de 128 identités candidates ; l’archivage ne promet ni admissions ni stockage illimités.

Les objets structurels locaux v1.45 ne nécessitent aucune migration. Un prototype protégé non publié ne devient jamais implicitement qualifié. Runtime en pause, flywheel migrate, signé par le contrôleur et lié à l’état exact, conserve les originaux, retire ses candidats et initialise le stockage actuel sans configuration. Les entrées d’invocation originales manquantes restent explicitement inconnues ; les anciens reçus ne deviennent pas une réutilisation qualifiée. flywheel archive et flywheel migrate exigent des objets signés via l’opérateur natif existant, jamais une action depuis la page publique.

Le propriétaire doit définir garde, sauvegarde chiffrée indépendante, rotation et récupération des clés. La rotation rechiffre les objets courants sous une clé active séparément provisionnée. Les sauvegardes historiques nécessitent encore les anciennes clés ; l’historique immuable n’est pas réécrit. Une clé perdue bloque l’accès. Charger une capsule ou configuration ne crée aucun secret ou droit de production.

Un DurableCheckpoint séparément provisionné reste hors de la reprise portable, idéalement sur une garde durable indépendante. Chaque mutation protégée ou comptable, consommation de permis modèle et accès réussi avancent ce seuil monotone avant la validation locale. Une panne entre les deux validations peut nécessiter une récupération explicite : elle bloque plutôt que d’accepter un Journal antérieur. Une ancienne sauvegarde ne peut restaurer silencieusement une révocation tant que la garde actuelle est conservée. Un fichier sur le même hôte n’est pas une durabilité distante indépendante ; restaurer les deux registres annule cette protection. Le seuil de tentative payante est validé avant l’appel fournisseur. Une sauvegarde portable antérieure ne peut réutiliser son permis tant que cette garde subsiste. Une facturation inconnue exige un rapprochement.

Découverte et invocation recontrôlent accès, dépendances et signataires révoqués. Un changement de modèle ou politique exige de nouvelles preuves. Une révocation terminale impose une nouvelle version. L’exécution contrôlée limite l’export direct ; les sorties peuvent révéler un comportement, surtout pour cette petite famille publique. Le texte divulgué et les comportements appris ne sont pas récupérables. Aucune rareté permanente ni croissance automatique d’un avantage défendable n’est revendiquée.

La qualification réelle exige : origine/hôte de service et stockage durable approuvés ; clés, registre de rôles et garde du seuil provisionnés indépendamment ; deux lecteurs RPC et vraies empreintes ; exécuteur/modèles approuvés avec allocation financière finie et preuves de quota/facturation ; deux portefeuilles d’agents admissibles contrôlés par leurs propriétaires pour signer des défis nouveaux. Aucune clé privée ou phrase de récupération ne doit être fournie dans l’application ou le dépôt.

Recorded evidence / Preuves enregistrées

Executed conformance example and source identities contains actual local software receipts with fictional model/ENS/cost attestations. It establishes no live qualification.

L’exemple de conformité et les identités des sources contiennent les reçus logiciels locaux et des attestations modèle/ENS/coûts fictives. Aucune qualification réelle.

With source-checkout test dependencies installed, reproduce a new record using:

Avec les dépendances de test du dépôt installées, créer un nouvel enregistrement avec :

python scripts/record_protected_flywheel_conformance.py --output /private/new-conformance.json

The command uses ephemeral test identities and refuses to overwrite an existing output. It executes native Research work and the bounded selector locally. Its costs, acceptance signers, model receipts and ENS state remain fictional; it cannot qualify a paid mission, frontier Alpha or a live network.

La commande emploie des identités de test éphémères et refuse d’écraser une sortie. Elle exécute le travail Research natif et le sélecteur borné localement. Coûts, signataires d’acceptation, reçus modèles et état ENS restent fictifs ; elle ne qualifie ni mission payée, Alpha frontière ou réseau réel.