Automatiseringsprogramvare for prediksjonsmarkeder bør gjøre fullmakter uttrykkelige. En komponent som leser offentlige data, trenger ikke nødvendigvis tilgang til en privat konto. En modell som foreslår en handling, bør ikke automatisk få lov til å sende den inn. En innsendingskomponent bør ikke opprette ny eksponering bare fordi et tidligere svar er ukjent. Disse grensene avgjør hvordan systemet oppfører seg når vanlig arbeid blir usikkert.
Det andre kravet er tydelig unntakshåndtering. Manglende dokumentasjon, nektet tillatelse, en delvis utført ordre og et avstemmingsavvik er ulike forhold. Å behandle alle som en generell feil fulgt av et nytt forsøk kan gjøre et håndterlig problem til dupliserte handlinger eller en misvisende kontotilstand.
Denne veiledningen utvikler en hypotetisk tillatelses- og gjenopprettingsutforming. Den beskriver ikke et bestemt produkts gjeldende implementering og godkjenner ingen virkelig handel. Målet er et system der egenskapene er begrenset til tildelt ansvar, og der postene forklarer hva som skjedde når en forutsetning manglet eller et eksternt svar var uklart.
Definer rollene til automatiseringsprogramvaren for prediksjonsmarkeder
Skill observasjon, anbefaling, godkjenning, innsending og avstemming. Observasjon samler dokumentasjon. Anbefaling anvender en metode på dokumentasjonen. Godkjenning kontrollerer om en bestemt foreslått handling er tillatt nå. Innsending skaper et eksternt forsøk. Avstemming fastslår hva som faktisk skjedde, og hvordan kontoen endret seg.
Én applikasjon kan implementere alle fem roller, men avgjørelsene og tillatelsene bør kunne skilles fra hverandre. Én funksjon kalt handle kan skjule flere viktige vurderinger. En gransker bør kunne identifisere dokumentasjonen som ble brukt, regelen som tillot handlingen, og postene som støtter det endelige utfallet.
Den eldre veiledningen om automatisering av handel i prediksjonsmarkeder forklarer hvordan tilstandene holdes sammen. En tydelig rollemodell hindrer at en gjentatt observasjon forveksles med ny godkjenning, og hindrer at en innsendt forespørsel registreres som en fullført posisjon før dokumentasjonen støtter det.
Bygg en tillatelsesgrense for automatiseringen
En tillatelsesgrense for automatisering angir hva en komponent kan lese og endre. Offentlige markedsdata, private kontodata, ordreinnsending og flytting av midler er ulike egenskaper. Gi bare fullmakten komponentens faktiske oppgave trenger, og gjør omfanget synlig for operatøren.
En undersøkelseskomponent kan ofte arbeide uten handlingsfullmakt. En forslagsgenerator kan trenge markeds- og kontokontekst og likevel ikke trenge tillatelse til innsending. En avstemmingskomponent kan trenge private poster uten å ha noen grunn til å opprette en ordre. Å kombinere disse tillatelsene av bekvemmelighet øker betydningen av uttrykkelige interne kontroller.
Den offisielle dataveiledningen for Polymarket US beskriver bruk av markedsdata med kun lesetilgang separat. Den generelle utformingslærdommen er at informasjonstilgang og handelsfullmakt er ulike ansvarsområder. Kontroller dagens faktiske tillatelsesmodell for valgt handelsplass og integrasjon fremfor å anta at kjente etiketter innebærer et bestemt omfang.
Bevar handelsplass- og kontokontekst
Hver godkjente handling bør identifisere handelsplass, konto, kontrakt og utfallsvalg. En generell markedstittel er utilstrekkelig. Lignende kontrakter kan ha ulike vilkår, og saldoer eller tillatelser fra én konto bør ikke antas tilgjengelige i en annen.
Polymarket International og Polymarket US er separate kontekster. Den offisielle utviklersiden for Polymarket US omtaler dens egen kontobaserte API-tilgang. Automatisering bør ikke overføre implementeringsantakelser, påloggingsopplysninger eller kontraktskoblinger fra International til US-arbeidsflyter bare fordi navnene er beslektet.
Veiledningen om en handelsplattform for hendelseskontrakter utdyper plattformkrav. I automatisering er det praktiske akseptansevilkåret at konteksten ikke kan endres stilltiende mellom anbefaling og innsending. Et forslag gyldig for én konto er ikke automatisk gyldig for en annen med ulike tillatelser, forpliktelser eller tilgangskrav.
Behandle kontraktsregler som en forutsetning
Systemet trenger en nøyaktig kontraktsdefinisjon før det kan tolke en prognose eller godkjenne en handling. Registrer kilde, terskel, tidspunkt og unntaksbestemmelser relevante for utbetalingen. Et overskriftstreff bør produsere en undersøkelseskandidat, ikke automatisk instrumentlikeverdighet.
Hvis regelkoblingen er ufullstendig, kan anbefalingen forbli uavklart. Godkjenning bør ikke veie opp for dette ved å redusere størrelse og samtidig late som instrumentet er forstått. Noen manglende inndata er forutsetninger fordi de definerer handlingens betydning, fremfor bare å påvirke risikomengden som tas.
Veiledningen om handel med hendelseskontrakter forklarer forholdet mellom regler, kostnader og oppgjør. Automatisering bør bevare betydningen gjennom alle postene. En senere regelpresisering kan ugyldiggjøre et forslag selv om markedsprisen og kontosaldoen ikke har endret seg.
Gi anbefalinger ingen underforstått fullmakt
En anbefaling er et analyseresultat under oppgitte forutsetninger. Den bør identifisere kontrakt, tiltenkt handling, dokumentasjonstid, modellversjon og begrensninger. Den kan være nyttig uten å kunne gjennomføres. Et godkjenningstrinn i neste ledd må fortsatt anvende dagens regler og kontobegrensninger.
Den eldre veiledningen om en KI-handelsbot for prediksjonsmarkeder forklarer avgrensede modellavgjørelser. En modells sikre språk eller tallpoengsum bør ikke endre tillatelsene. Eksternt innhold brukt som dokumentasjon bør behandles som data, ikke som instrukser som kan omskrive grenser eller be om uvedkommende handlinger.
Send et strukturert forslag med uttrykkelige felt fremfor en fritekstkommando som bygger på tolkning. Systemet bør vite hvilke verdier som er observasjoner, hvilke som er modellvurderinger, og hvilke som krever godkjenning etter regelen. Dette gjør det vanskeligere for tvetydighet i et undersøkelsessammendrag å bli ubegrenset handlingsfullmakt.
Godkjenn én bestemt forslagsversjon
Godkjenning bør bindes til faktisk kontrakt, konto, side, mengde, prisvilkår og dokumentasjonsversjon. Hvis disse inndataene endres vesentlig, trenger systemet en definert oppdaterings- eller avvisningsprosess. En tidligere godkjenning bør ikke bli en stående tillatelse til å handle enhver mengde under senere forhold.
Sett et utløpsvilkår som passer arbeidsflyten. Et forslag kan utløpe fordi tid gikk, en kilde ble utdatert, en kontrakt endret tilstand eller kontoen fikk nye forpliktelser. Utløpet bør registreres som en endring i handlingskvalifikasjon, ikke som sletting av den underliggende undersøkelsen.
Godkjenningsposten bør forklare hvilke grenser som ble kontrollert, og hvilken som begrenset forslaget. Dette er nyttig både for vanlig gjennomgang og ved hendelser. En gransker kan skille en strategiavgjørelse fra en kontantkapasitetsgrense eller en driftspause uten å gjette ut fra endelig mengde alene.
Gjør avgrenset handelsfullmakt målbar
Avgrenset handelsfullmakt trenger konkrete grenser. Disse kan gjelde tillatte kontoer og kontrakter, maksimal ny eksponering, prisgrenser, krav til ferske data og driftstilstander. De nøyaktige valgene avhenger av den godkjente arbeidsflyten; denne veiledningen foreskriver ingen universelle innstillinger.
Bruk grenser systemet kan evaluere fra underbygd dokumentasjon. En vag instruks om å unngå risikable handler er ingen operativ grense. Et krav om at dagens kontraktskobling er bekreftet, eller at et uavklart tidligere forsøk blokkerer ny eksponering, er mer konkret og kan testes.
Bevar enheter og aggregeringsregler. En kontraktsantallsgrense kan være upassende når utbetalingsstrukturer avviker, mens en kontantgrense kan overse felles hendelseseksponering. Regelen bør oppgi hva den måler, og hvorfor. Et presist tall knyttet til en uklar risikodefinisjon kan skape falsk trygghet.
Skill regelbasert avslag fra teknisk feil
Et forslag som avvises av regler, er ikke nødvendigvis en programvarefeil. Det kan overstige en eksponeringsgrense, bygge på utdatert dokumentasjon eller gjelde en kontrakt som ikke støttes. Systemet bør rapportere begrunnelsen og bevare forslaget for gjennomgang uten automatisk å prøve samme handling igjen.
En teknisk feil gjelder evnen til å fullføre et trinn, som å hente en påkrevd kontopost. Den kan etterlate avgjørelsen som ukjent fremfor avvist på sitt eget grunnlag. Neste oppgave er å gjenopprette dokumentasjon eller avstemme tilstand, ikke å svekke regelen til forespørselen består.
Den eldre veiledningen om API for boter i prediksjonsmarkeder bidrar til å skille grensene. Tydelig statusspråk hindrer at en operatør behandler hver mislykkede handling som noe som må tvinges gjennom. Korrekt avslag er del av systemets tiltenkte atferd og bør være synlig i evalueringen.
Bygg en post for unntakshåndtering
En post for unntakshåndtering bør identifisere berørt forslag eller forsøk, kjente fakta, uavklart spørsmål, tillatte gjenopprettingshandlinger og endelig løsning. Behold opprinnelig hendelsestid og tidspunktet unntaket ble oppdaget. Disse kan avvike, særlig etter forsinkede data eller omstart.
Posten bør skille årsak fra symptom. En utdatert ordrebok kan skyldes kildeavbrudd eller lokal behandlingsforsinkelse. Et kontoavvik kan gjenspeile en ekstern handling, en manglende utførelse eller en regnskapsfeil. Ikke tilordne en endelig årsak før dokumentasjonen støtter den.
En kortfattet post kan fortsatt være nyttig. Den bør la en annen operatør forstå hva som må kontrolleres videre, og hvilke handlinger som fortsatt er blokkert. Unngå en generell feilstreng som tvinger leseren til å rekonstruere hele arbeidsflyten fra spredte logger før det kan fastslås om eksponering finnes.
Henvis og tjen USDC
Henvis og tjen USDCPartnerprogrammet vårt betaler i sanntid.
Gjenopprett forsiktig etter ukjent innsending
Et ukjent innsendingsutfall betyr at systemet ennå ikke vet hva som skjedde med et eksisterende forsøk. Det tilsvarer ikke avslag eller fravær av eksponering. Å opprette en ny ordre kan duplisere tiltenkt handling hvis første forsøk ble fullført eller fortsatt er aktivt.
Bevar forsøksreferansen og hent støttet ordre- og kontodokumentasjon etter den faktiske handelsplassens gjeldende atferd. Hvis en mekanisme for nye forsøk finnes, fastslå om den gjentar samme logiske forespørsel eller oppretter en ny. Skillet bør være uttrykkelig både i implementeringen og kontrollene operatøren ser.
Veiledningen om programvare for automatisering av handel i prediksjonsmarkeder undersøker fullstendige feilscenarioer. En robust gjenopprettingsvei kan forbli uavklart ved behov og samtidig hindre ytterligere handlinger som avhenger av kunnskap om kontoen. Den bør ikke fabrikere sikkerhet bare for å holde arbeidsflyten i gang.
Håndter delvise utførelser som en ny kontotilstand
En delvis utførelse endrer posisjonen; en eventuell fortsatt aktiv rest forblir en forpliktelse. Noen instrukser for umiddelbar gjennomføring kansellerer uutført mengde fremfor å la den stå åpen. Avstem ordretypen og endelig reststatus før reservert kapasitet oppdateres. En ny anbefaling må ikke ignorere verken utført eksponering eller en bekreftet fortsatt åpen rest.
For en hypotetisk hvilende ordre på 100 kontrakter krever 30 utførelser og 70 fortsatt åpne separate poster. Hvis kansellering forespørres, kan endelig tilstand fortsatt omfatte flere utførelser før kanselleringen trer i kraft. Systemet må avstemme faktisk rekkefølge etter handelsplassens atferd fremfor å anta at knappetrykket fjernet all gjenværende eksponering.
Gjenopprettingsregelen bør oppgi om resten kan forbli åpen, kanselleres eller kreve gjennomgang når den opprinnelige dokumentasjonen utløper. Dette er handlingsavgjørelser med egen fullmakt. De bør ikke improviseres av en generell unntaksbehandler med eneste mål å få ordrestatusen til å se fullført ut.
Definer hva en pause faktisk stopper
En pause kan stoppe nye anbefalinger, nye godkjenninger eller nye innsendinger. Den reverserer kanskje ikke fullførte utførelser eller fjerner allerede aktive forpliktelser. Grensesnittet bør angi omfanget tydelig, slik at operatøren ikke antar at en bred stoppet-etikett betyr at kontoen ikke lenger kan endres.
Avstemming må ofte fortsette under en pause. Forsinkede utførelser eller oppgjørsoppdateringer kan fortsatt komme og må registreres. Systemet bør ikke miste oversikten over utestående forsøk bare fordi ny handling er deaktivert. Omvendt bør en innkommende oppdatering ikke automatisk gjenoppta handel.
Definer dokumentasjonen som trengs for gjenopptakelse. Den kan omfatte ferske kilder, bekreftet kontraktstilstand og avstemte kontoposter. En tidtaker alene bør ikke oppheve et uavklart forhold med mindre regelen uttrykkelig begrunner atferden. Fullmakt til gjenopptakelse er en separat avgjørelse og bør vises i posten.
Håndter tillatelsesendringer uten å forveksle dem med markedet
Påloggingsopplysninger kan utløpe, tillatelser kan trekkes tilbake, og kontotilgang kan endres. Programvaren bør identifisere dette som fullmakts- eller tilkoblingstilstander fremfor å presentere dem som markedsutilgjengelighet eller ugunstige priser. Leseren må vite om problemet gjelder instrumentet eller systemets evne til å handle.
En undersøkelsesfunksjon med kun lesetilgang kan fortsette mens innsendingsfullmakten er utilgjengelig. Hold skillet synlig. Modellen kan fortsatt lage et undersøkelsesanslag, men handlingsforløpet bør forbli blokkert under dagens tillatelsestilstand. Et nyttig grensesnitt forklarer grensen uten å gjøre hver skjerm til en generell feil.
Registrer tillatelsesendringer med omfang og virkningstidspunkt der det er kjent. Hvis et forsøk allerede er sendt inn, fastslår ikke tilbakekalling av fremtidig fullmakt utfallet. Systemet må fortsatt avstemme forsøket gjennom støttet dokumentasjon og bevare eventuell gjenværende usikkerhet i kontoposten.
Hindre at ekstern dokumentasjon omskriver regler
Nyheter, dokumenter og markedsbeskrivelser er inndata til undersøkelser. De er ikke instrukser om å endre kontotillatelser, omgå grenser eller sende uvedkommende informasjon. En automatisert arbeidsflyt bør bevare skillet selv når en språkmodell leser materialet og oppsummerer det til et forslag.
Hold reglene i en kontrollert kilde med uttrykkelig endringsfullmakt. En kildeartikkel som hevder at en handel haster, bør ikke overstyre prisgrenser eller datakrav. Modellen kan rapportere påstanden som dokumentasjon, med kildeangivelse og usikkerhet, mens godkjenningskomponenten anvender eksisterende regler uavhengig.
Test et dokument med språk som ligner en instruks til programvaren. Forventet atferd er å behandle det som upålitelig innhold bare relevant for undersøkelsesoppgaven, hvis det er relevant overhodet. Dette akseptansescenarioet beskytter grensen mellom å forstå ekstern informasjon og å gi informasjonen kontroll over systemet.
Avstem kontoen før gjenoppretting erklæres fullført
Gjenoppretting er først fullført når relevant usikkerhet er avklart i den grad arbeidsflyten krever. At en feil forsvinner fra grensesnittet, er utilstrekkelig. Sammenlign forsøk, utførelser, gebyrer, posisjoner og tilgjengelig kapasitet ved hjelp av passende kontodokumentasjon.
For en hypotetisk hendelse med delvis utførelse bør posten vise endelig ervervet mengde, statusen til eventuell rest og resulterende kontogrenser. Hvis et avvik består, bevar det og hold avhengige handlinger begrenset etter regelen. Ikke tving loggen til å stemme ved å forkaste ubeleilige poster.
Behold en varig eksport eller gjennomgangspost. Operatøren bør kunne forklare hendelsen etter at det aktive systemet har gått videre. Dette støtter læring og hindrer at samme tvetydige status gjentar seg uten en tydeligere reaksjon. Det skiller også vellykket gjenoppretting fra bare å undertrykke et varsel.
Test unntak som sentral atferd
Forbered kontrollerte scenarioer for manglende regler, utdaterte ordrebøker, nektet fullmakt, ukjent innsending, delvise utførelser, ekstern kontoaktivitet og forsinket oppgjør. Hvert bør ha en forventet tilstand og tillatte neste handlinger. Testen er meningsfull når den kontrollerer arbeidsflytens faktiske grenser fremfor å duplisere interne implementeringsdetaljer.
Ta med tilfeller der riktig resultat er fortsatt usikkerhet eller avslag. Et system som alltid fullfører en handling, kan være mindre pålitelig enn ett som stopper med en tydelig begrunnelse. Evalueringen bør belønne nøyaktig tilstand og avgrenset atferd, ikke bare et høyt antall vellykkede innsendinger.
Gjenta relevante scenarioer etter vesentlige endringer i tillatelser, handelsplassintegrasjon eller ordrehåndtering. Bevar versjoner og datoer. Gjeldende offisiell dokumentasjon styrer faktisk API- og kontoatferd, så en historisk antakelse bør ikke stilltiende forbli grunnlaget for en endret integrasjon.
Gjennomgå overleveringen til mennesker under et unntak
Når automatisering trenger en person, bør meldingen identifisere avgjørelsen som kreves, og tilgjengelig dokumentasjon. Å gjennomgå kontraktskoblingen, avstemme eksisterende forsøk og godkjenne en regelendring er ulike oppgaver. En vag forespørsel om å fikse boten overfører for mye rekonstruksjonsarbeid til operatøren.
Personen bør se hvilke handlinger som fortsatt er blokkert, og hva som kan fortsette trygt innenfor arbeidsflytens fullmakt. Undersøkelser med kun lesetilgang kan forbli tilgjengelige mens ordreoppretting er på pause. En holdt posisjon trenger fortsatt overvåking selv når anbefalingsmotoren er utilgjengelig. Overleveringen bør bevare skillene.
Registrer den menneskelige avgjørelsen og omfanget. En engangsgodkjenning for en bestemt gjenopprettingshandling bør ikke bli et permanent regelunntak. Systemet bør gå tilbake til normale grenser etter at saken er løst, med en tydelig historikk over hva som midlertidig var tillatt, og hvorfor.
Automatiseringsprogramvare for prediksjonsmarkeder trenger uttrykkelige fullmakter
Den fullførte utformingen bør gjøre det mulig å svare på hvem eller hva som observerte, anbefalte, godkjente, sendte inn og avstemte hver handling. Den bør også forklare hvilken tillatelse og dokumentasjon som støttet hver overgang. Posten er nyttig selv når riktig resultat var ingen handling.
De hypotetiske unntakene viser hvorfor ett generelt prøv igjen er utilstrekkelig. Manglende dokumentasjon krever innsamling eller avståelse, nektet tillatelse krever fullmaktsgjennomgang, ukjent innsending krever avstemming, og delvise utførelser krever oppdatert kontoresonnement. Å behandle tilstandene separat hindrer at usikkerhet blir utilsiktet ny eksponering.
Bygg tillatelser og unntakshåndtering inn i kjernearbeidsflyten. Hold handelsplasskontekst, kontraktsbetydning og forslagsversjoner uttrykkelige, og bevar dokumentasjonen som trengs for gjenoppretting. Resultatet er automatisering der atferden forblir forståelig når forhold endres, mens fullmakten forblir avgrenset av oppgaven den faktisk fikk lov til å utføre.