Tekniska frågor
Tekniskt förtroende bör komma från underlag, inte från adjektiv
Specify är före produktion. Den här sidan beskriver det system vi bygger mot och hur det är utformat, så att en teknisk läsare kan bedöma om ingenjörsarbetet är seriöst innan något står på spel.
Designprinciperna är isolering, hållbarhet, kontrollerad förändring, observerbar drift och en uttrycklig gräns mellan vad mjukvara får tolka och vad ett företag faktiskt har godkänt. Det sista är det de flesta handelssystem får om bakfoten, och det är det Specify är byggt kring.
Nuvarande skede: Före produktion
Plattformen är under aktiv utveckling och validering och omfattas ännu inte av ett publikt produktionsåtagande om tillgänglighet. Kontroller som nedan beskrivs som produktionskrav är designåtaganden snarare än utfört arbete, och vi beskriver inte en föreslagen skyddsåtgärd som om den redan vore testad.
Så är det designat
Fem principer arkitekturen vilar på
Det är beslut som fattats tidigt, eftersom vart och ett blir dyrt att eftermontera. Det är dem en arkitekt skulle vilja syna först.
- Fel innesluts, de förhindras inte
- Systemet är utformat att fela på avgränsade, observerbara och återställbara sätt snarare än att hävda att det inte kommer att fela. Valfri kapacitet försämras utan att ta med sig de centrala kommersiella registreringarna, och långvarigt eller felbenäget arbete är isolerat från anropsvägen. Den publika webbplatsen är helt förrenderad utan server vid anropstillfället, så den förblir tillgänglig oberoende av allt bakom.
- Behörighet är uttrycklig och skild från tolkning
- Tolkande tjänster har ingen stående behörighet att ändra kommersiella registreringar eller binda en handlare. Vad som får erbjudas kommer från godkänd kapacitet, begränsningar och prisregler, upprätthållna deterministiskt. Det är arkitektoniskt snarare än procedurmässigt: gränsen håller oavsett vad någon prompt eller modell gör.
- Tenantskap upprätthålls i datalagret
- Behörighet landar i en frågebegränsning snarare än en kontroll en anropare kan påverka, så en förfrågan avgränsas till den handlare den tillhör innan data läses snarare än att filtreras efteråt. Isoleringen täcks av tester på både enhets- och integrationsnivå.
- Tillstånd är hållbart och schemaändring är avsiktlig
- Auktoritativa kommersiella data ligger i hanterad PostgreSQL, där schemaändringar införs genom granskade, versionshanterade migreringar snarare än automatisk synkronisering, och tillämpas före den kod som beror på dem.
- Operationer är idempotenta
- Omförsök och omleverans är förväntade tillstånd snarare än undantag. Att upprepa en operation får inte skapa en dubbel kommersiell registrering, ett dubbelt meddelande eller en dubbel extern åtgärd.
Pålitliga system är utformade att fela på inneslutna, observerbara och återställbara sätt.
Produktionsdesign
Hur produktion ser ut, och var vi står i förhållande till det
Designen är fastställd. En del av den är byggd och i bruk i utveckling i dag; resten är produktionskrav vi håller oss själva till innan vi tar emot kundlast.
- Byggt och i bruk
Topologi
En statiskt serverad publik webbplats vid kanten, och separat utrullade applikationstjänster bakom den: en handlarapplikation, ett commerce-API, en innehållstjänst och bakgrundsarbetare. Separata utrullningar med separata feltillstånd, så att en incident på ett ställe inte blir ett avbrott överallt.
- Byggt och i bruk
Identitet och åtkomst
Hanterad identitet med OIDC authorisation-code-flödet och PKCE, HttpOnly-sessionscookies och rollbaserad behörighet som tillämpas på serversidan. Administrativ åtkomst är skild från vanlig handlaråtkomst.
- Byggt och i bruk
Isolering mellan tenanter
Avgränsning till handlare tillämpas som en begränsning i datalagret snarare än ett filter i applikationen, och tenantidentitet hämtas aldrig från ett värde anroparen anger. Åtkomst över tenantgränser testas snarare än förutsätts.
- Byggt och i bruk
Ändring och leverans
Varje ändring granskas, byggs en gång och testas automatiskt innan den når någon miljö, inklusive integrationstester mot en riktig databas. Schemamigreringar körs före den kod som beror på dem.
- Produktionskrav
Produktionsutrullning
Godkännandestyrd produktionsutrullning med stegvis utrullning, hälsoportar på felfrekvens, svarstid och slutförande av kritiska arbetsflöden, samt en testad återställningsväg. Bakåtkompatibla migreringar, där destruktiv upprensning är skild från den ändring som inför den.
- Produktionskrav
Hållbarhet och återställning
Automatiserade krypterade säkerhetskopior med definierad lagringstid och raderingsskydd, återställning till en tidpunkt, och replikering anpassad till de felklasser den ska hantera. Återställningsmål fastställs när en återställning faktiskt har utförts och tidtagits, inte innan.
- Produktionskrav
Observerbarhet
Strukturerad telemetri korrelerad över tjänster, servicenivåindikatorer definierade mot kritiska kundresor snarare än processliv, och syntetiska kontroller som genomför ett verkligt arbetsflöde. Känsliga värden utesluts från loggar genom konstruktion snarare än genom efterhandsmaskering.
- Produktionskrav
Driftrespons
Larm kopplade till kundsynliga fel, vart och ett med en ansvarig, en eskaleringsväg och en handbok, testade från början till slut före lansering. En definierad allvarlighetsmodell, en publik statuskanal och en proportionerlig genomgång efter varje väsentlig incident.
- Produktionskrav
Säkerhetssäkring
Automatiserad beroende- och hemlighetsskanning i pipelinen, ett hanterat hemlighetsvalv med rotation, och oberoende säkerhetstestning beställd vid lansering och vid väsentliga riskmilstolpar. Fynd åtgärdas och omtestas innan de beskrivs som lösta.
Abonnemanget bidrar till att finansiera det ingenjörs- och driftarbete som krävs för att gå från förproduktion mot en pålitlig produktionstjänst. Att betala för något gör det inte produktionsklart, och den här sidan påstår inget annat; det priset köper är arbetet, inte statusen.
Det är avsiktligt den nivå en arkitekt behöver för att bedöma ansatsen. En kontroll-för-kontroll-redogörelse för vad som är implementerat, testat och utestående finns tillgänglig för kunder, partner och granskare under ett lämpligt avtal, och formuläret nedan är vägen dit.
AI-kontroller
Tolkning är inte behörighet
AI kan hjälpa till att förstå en förfrågan. Den fastställer inte självständigt vad en handlare har godkänt.
Merparten av den kommersiella risken i ett AI-stött system uppstår när ett sannolikt svar förväxlas med ett godkänt. Specify behandlar det som ett arkitekturproblem snarare än ett promptproblem, eftersom en gräns som upprätthålls med instruktioner inte är en gräns.
- Identitet är inte ett modellindata
- Vilken handlare en förfrågan tillhör fastställs utifrån den autentiserade sessionen och infogas på serversidan. Det är inget en modell kan hävda, och ett försök att ange det avvisas snarare än ignoreras.
- Kapaciteten är avgränsad genom konstruktion
- De åtgärder assistenten har tillgång till är fastlagda i kod snarare än sammansatta vid körning, och destruktiva operationer ingår inte. Ingen prompt kan vidga dem.
- Ändringar klassificeras deterministiskt
- Varje föreslagen ändring bedöms av en policymotor som körs på den resulterande ändringen snarare än på uttalad avsikt. Allt oklassificerat nekas som standard, och handlar- eller plattformsöverstyrningar får bara skärpa en klassificering, aldrig mildra den.
- Kommersiellt känsliga data ligger utanför räckvidden
- Prisunderlag, leverantörsvärden och interna fält är uteslutna från det modellen överhuvudtaget kan läsa, snarare än filtrerade från det den producerar.
- Icke betrott innehåll behandlas som icke betrott
- Handlar- och kundinnehåll hanteras som data snarare än som instruktion. En injektion kan i värsta fall producera en föreslagen åtgärd, som policymotorn sedan bedömer på dess egna meriter.
- Otillgänglighet försämras säkert
- När modellleverantören är långsam, fallerar eller inte är konfigurerad rapporterar assistenten sig som otillgänglig och förfrågan bevaras. Ingenting hittar på ett svar för att dölja ett fel.
Systemprompten behandlas inte som en säkerhetskontroll, för det är den inte. Varje gräns ovan upprätthålls i deterministisk kod, vilket är det enda skälet till att den alls kan beskrivas som en kontroll här.
Tekniska frågor
De frågor granskare ställer
Besvarade direkt, även där svaret är nej.
Är Specify i produktion?
Nej. Specify är före produktion och genomgår produkt-, infrastruktur-, säkerhets- och driftvalidering. Allt som på den här sidan beskrivs som ett produktionskrav är ett designåtagande snarare än utfört arbete.
Var hostas Specify?
På Microsoft Azure, med den publika webbplatsen statiskt serverad vid kanten och applikationstjänsterna separat utrullade bakom den. Hanterad PostgreSQL rymmer auktoritativa kommersiella data och objektlagring rymmer media. Regioner, resurskonfiguration och nätverksdetaljer delas under en teknisk granskning snarare än publiceras.
Vilket tillgänglighetsåtagande gäller?
Inget än, och vi publicerar ingen siffra innan den är mätbar. En indikator är det som mäts, ett mål är en intern målsättning och ett avtal är ett kontraktuellt åtagande med påföljder. De tre är olika saker och vi använder dem inte omväxlande.
Hur skyddas data mot förlust?
Genom automatiserade krypterade säkerhetskopior med definierad lagringstid och raderingsskydd, återställning till en tidpunkt, och replikering anpassad till de felklasser den hanterar. Replikering och säkerhetskopior löser olika problem och det ena ersätter inte det andra. Återställningsmål publiceras när en återställning har utförts och tidtagits snarare än uppskattats.
Kan Specify rulla ut utan driftstopp?
Produktionsmålet är att rulla ut rutinmässiga kompatibla ändringar utan att avbryta kritiska arbetsflöden, genom stegvis utrullning och hälsoportar. Visst underhåll, infrastrukturändringar och akuta operationer kan fortfarande kräva ett kontrollerat avbrott, och det säger vi hellre än lovar något annat.
Hur isoleras kunddata?
Behörighet landar i en begränsning i datalagret, så en förfrågan avgränsas till den handlare den tillhör innan data läses snarare än att filtreras efteråt, och tenantidentitet hämtas aldrig från ett värde anroparen anger. Åtkomst över tenantgränser täcks av tester på enhets- och integrationsnivå.
Kan AI godkänna en offert eller ett åtagande?
Nej. AI får hjälpa till att tolka och strukturera en förfrågan. Kommersiell behörighet kommer från godkänd kapacitet, begränsningar, prisregler och behöriga mänskliga eller deterministiska kontroller, och policymotorn nekar varje ändring den saknar klassificering för.
Används kunddata för att träna AI-modeller?
Nej. Inskickad kund- och företagsinformation används inte för att träna allmänna modeller. Vad som skickas till en modellleverantör, och varför, framgår av integritetspolicyn.
Har Specify genomfört ett penetrationstest eller en certifieringsrevision?
Nej. Oberoende säkerhetstestning beställs vid lansering och vid väsentliga riskmilstolpar. När en bedömning sker anger vi dess typ, omfattning, datum, granskarens oberoende och om väsentliga fynd åtgärdats, snarare än att vagt hänvisa till att ha blivit reviderade.
Vilka standarder arbetar ni efter?
Vårt ingenjörsprogram använder NIST Cybersecurity- och Secure Software Development-ramverken, OWASP Application Security Verification Standard och CISA Secure by Design-principerna som referenspunkter. En hänvisning till ett ramverk är inte detsamma som certifiering, oberoende säkring eller genomförd implementering, och Specify har ingen certifiering i dag.
Kan vi begära detaljerad säkerhetsdokumentation?
Ja. Arkitektursammanfattningar, kontrollredogörelser, information om underbiträden, databehandlingsvillkor och svar på frågeformulär finns tillgängliga under ett lämpligt avtal via formuläret nedan. Vi publicerar ingen detaljerad kontrollförteckning på en publik adress, och vi säger till när något inte finns än i stället för att skicka ett närliggande dokument.
Var kan jag se aktuell driftstatus?
På statussidan, som rapporterar tillståndet före produktion och inte visar någon produktionssiffra för tillgänglighet, eftersom det ännu inte finns någon produktionstjänst att mäta.
Teknisk kontakt
Ställ en teknisk fråga
Kunder, partner och investerare kan begära teknisk, säkerhetsmässig eller driftmässig information som det inte är lämpligt att publicera öppet. Arkitektursammanfattningar, listor över underbiträden, databehandlingsvillkor och svar på frågeformulär finns alla tillgängliga den här vägen.
Ange inte lösenord, åtkomsttokens, privata nycklar eller känsliga produktionsdata i det här formuläret.
Fråga
Ställ en teknisk fråga
Kunder, partner och granskare kan begära den tekniska, säkerhetsmässiga och driftmässiga detalj som det inte är lämpligt att publicera öppet.