Så bygger du en sökbar AI-kunskapsbas för möten med schema, styrning och tester av informationssökning.
Skriven av Hinoter, redaktör för kunskapsarkitektur · Granskad för granskning av styrningen av kunskapsbasen · Test- och evidensstatus: metodik publicerad; produktbeteende kräver verifiering i verklig miljö · Publicerad och uppdaterad 2026-09-07
En AI-kunskapsbas för möten fungerar när posterna har stabila metadata, källänkar, styrning, granskningsstatus och tester av informationssökning – inte bara volym. Kontrollera jobb för informationssökning, schema, styrning, proveniens, aktualitet, åtkomst och korrigeringstester. volym utan styrning skapar ett sökbart arkiv som ändå ger svar med föråldrad, duplicerad eller obehörig information Använd endast slutsatsen för de mötestyper, språk, talare, konfigurationer och granskningsgränser som faktiskt har testats. Om evidens saknas, markera fältet N/A och bevara källan för ett mänskligt beslut.

Frågan bakom AI för kunskapsbaser för möten låter enkel, men det användbara svaret beror på vad mötesposten ska göra härnäst. ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem
Den här guiden till att bygga en kunskapsbas för möten är avsedd för driftteam, kunskapsansvariga och tekniska ledare som använder Notion, Slack, Google Docs, kalendrar, e-post och automatiseringsverktyg. Den skiljer mellan förstahandsdokumentation, återgivna observationer, redaktionella rekommendationer och N/A-poster så att ett välformulerat resultat inte springer före sin evidens.
Den operativa regeln är snäv: bygg en kunskapsbas för möten kring deklarerade informationssökningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Metoden gäller endast den angivna mötestypen, källmaterialet, språk- eller rollvillkoren, datumet och granskningsgränsen.
En kunskapsbas börjar med ett användningsfall – AI-kunskapsbas för möten
Det användbara testet här omfattar insamlingsomfång, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och informationssökningsuppgifter.
Arbetsregel: En kunskapsbas börjar med ett användningsfall – AI-kunskapsbas för möten godkänns när källan är länkad. Den misslyckas väsentligt när sammanfattningen behandlas som slutgiltig sanning. Håll insamlingsomfång, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och informationssökningsuppgifter synliga, eftersom en välformulerad mening inte kan tillhandahålla evidens som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem. I scenariot med kundhistorik granskar du godkänd kontext och tillämpar åtkomstgranskning som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att behandla en modells självförtroende som ett godkännande.
Beslut för det här avsnittet: bygg en kunskapsbas för möten kring deklarerade informationssökningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om kedjan till källan bryts, börja med en begränsad insamling, dokumentera policy och ägarskap och utöka först efter att informationssöknings- och korrigeringstesterna har godkänts. Dokumentera vem som granskade posten och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om posten är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras i verklig miljö. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden till att bygga en kunskapsbas för möten, inte en fotnot.

Notering om evidens i guiden till att bygga en kunskapsbas för möten: Granska NIST – AI Risk Management Framework (källdatum: 2023-01-26; typ: auktoritativ källa; roll: fakta / kontext / begränsning) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Välj den minsta användbara posten
Det användbara testet här omfattar insamlingsomfång, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och informationssökningsuppgifter.
Arbetsregel: Välj den minsta användbara posten godkänns när informationssökningsjobben är uttryckliga. Den misslyckas väsentligt när arkivet växer planlöst. Håll insamlingsomfång, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och informationssökningsuppgifter synliga, eftersom en välformulerad mening inte kan tillhandahålla evidens som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem. I scenariot med driftwikin granskar du upprepningsbar policy och tillämpar aktualitetskontroller som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att behandla en modells självförtroende som ett godkännande.
Beslut för det här avsnittet: bygg en kunskapsbas för möten kring deklarerade informationssökningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om kedjan till källan bryts, börja med en begränsad insamling, dokumentera policy och ägarskap och utöka först efter att informationssöknings- och korrigeringstesterna har godkänts. Dokumentera vem som granskade posten och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om posten är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras i verklig miljö. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden till att bygga en kunskapsbas för möten, inte en fotnot.
| Godkännandepunkt | Godkänd evidens | Allvarligt fel |
|---|---|---|
| Syfte | hämtningsuppgifter är explicita | arkivet växer utan mål |
| Schema | fält stödjer beslut | alla anteckningar är blobbar |
| Styrning | ägare och policy finns | åtkomsten är oklar |
| Härkomst | källan är länkad | sammanfattningen är den slutgiltiga sanningen |
| Aktualitet | statusen för ersatt innehåll är synlig | ett inaktuellt svar vinner |
| Lärande | misslyckanden skapar en uppgiftslista | mätvärden hyllar volym |
Bevisanteckning för guiden om att bygga en möteskunskapsbas: Granska NIST — ramverk för riskhantering av artificiell intelligens: profil för generativ AI (källdatum: 2024-07-26; typ: auktoritativ källa; roll: fakta / kontext / begränsning) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Utforma metadata och länkar
Det användbara testet här är insamlingsomfattning, postschema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter.
Arbetsregel: Utformning av metadata och länkar godkänns när källan är länkad. Den underkänns allvarligt när sammanfattningen är den slutgiltiga sanningen. Håll insamlingsomfattning, postschema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter synliga, eftersom en polerad mening inte kan ge evidens för något som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande är aktuella eller vem som får korrigera dem. I scenariot med kundhistorik granskar du godkänd kontext och tillämpar åtkomstgranskning som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att behandla en modells säkerhet som ett godkännande.
Beslut för det här avsnittet: bygg en möteskunskapsbas kring deklarerade hämtningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om källkedjan bryts, börja med en smal samling, dokumentera policy och ägarskap och utöka först efter att tester av hämtning och korrigering har godkänts. Notera vem som granskade posten och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om posten är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras i realtid. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden för att bygga en möteskunskapsbas, inte en fotnot.

Bevisanteckning för guiden om att bygga en möteskunskapsbas: Granska NIST — verktygslåda för poängsättning av taligenkänning (källdatum: 2025-01-15; typ: auktoritativ källa; roll: fakta / kontext / begränsning) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Fortsätt med arbetsflöden för AI-möten, metoder för AI-anteckningar eller arbetsflöden för AI-översättning.
Samla in med granskningskontroller
Det användbara testet här är insamlingsomfattning, postschema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter.
Arbetsregel: Insamling med granskningskontroller godkänns när hämtningsuppgifterna är explicita. Den underkänns allvarligt när arkivet växer utan mål. Håll insamlingsomfattning, postschema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter synliga, eftersom en polerad mening inte kan ge evidens för något som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande är aktuella eller vem som får korrigera dem. I scenariot med driftwikin granskar du repeterbar policy och tillämpar aktualitetskontroller som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att behandla en modells säkerhet som ett godkännande.
Beslut för det här avsnittet: bygg en möteskunskapsbas kring deklarerade hämtningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om källkedjan bryts, börja med en smal samling, dokumentera policy och ägarskap och utöka först efter att tester av hämtning och korrigering har godkänts. Notera vem som granskade posten och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om posten är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras i realtid. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden för att bygga en möteskunskapsbas, inte en fotnot.
Bevisanteckning för guiden om att bygga en möteskunskapsbas: Granska W3C Internationalisering — välja en språktagg (källdatum: 2024-02-15; typ: auktoritativ källa; roll: fakta / kontext / begränsning) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Gör hämtning förutsägbar
Det användbara testet här är insamlingsomfattning, postschema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter.
Arbetsregel: Förutsägbar hämtning godkänns när källan är länkad. Den underkänns allvarligt när sammanfattningen är den slutgiltiga sanningen. Håll insamlingsomfattning, postschema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter synliga, eftersom en polerad mening inte kan ge evidens för något som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem. I scenariot Kundhistorik granskar du godkänd kontext och tillämpar åtkomstgranskning som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att betrakta en modells säkerhet som ett godkännande.
Beslut för det här avsnittet: bygg en möteskunskapsbas kring deklarerade hämtningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om källkedjan bryts börjar du med en avgränsad samling, dokumenterar policy och ägarskap och utökar först efter att tester av hämtning och korrigering har godkänts. Registrera vem som granskade posten och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om posten är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras live. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden för att bygga en möteskunskapsbas, inte en fotnot.

Bevisanteckning för guiden för att bygga en möteskunskapsbas: Granska Google Cloud — dokumentation för Cloud Speech-to-Text (källdatum: 2026-01-15; typ: auktoritativ källa; roll: fakta / kontext / begränsning) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Ett avgränsat HiNoter-arbetsflöde för kunskap
Det användbara testet här är samlingens omfattning, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter.
Arbetsregel: Ett avgränsat HiNoter-arbetsflöde för kunskap godkänns när hämtningsjobben är uttryckliga. Det misslyckas väsentligt när arkivet växer planlöst. Håll samlingens omfattning, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter synliga, eftersom en välformulerad mening inte kan tillhandahålla bevis för något som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem. I scenariot Operations-wiki granskar du upprepningsbar policy och tillämpar aktualitetskontroller som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att betrakta en modells säkerhet som ett godkännande.
Beslut för det här avsnittet: bygg en möteskunskapsbas kring deklarerade hämtningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om källkedjan bryts börjar du med en avgränsad samling, dokumenterar policy och ägarskap och utökar först efter att tester av hämtning och korrigering har godkänts. Registrera vem som granskade posten och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om posten är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras live. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden för att bygga en möteskunskapsbas, inte en fotnot.
| Mötes- eller testfall | Bevismål | Mänsklig gräns |
|---|---|---|
| Projektportal | åtgärder och beslut | pilotschema |
| Kundhistorik | godkänd kontext | åtkomstgranskning |
| Forskningsbibliotek | bevis och förbehåll | expertägare |
| Operations-wiki | upprepningsbar policy | aktualitetskontroller |
Bevisanteckning för guiden för att bygga en möteskunskapsbas: Granska HiNoter — HiNoter produktwebbplats (källdatum: 2026-09-03; typ: förstapartskälla från produkten; roll: kontext / produktverifiering) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Bygg en liten möteskunskapsbas: använd ett auktoriserat, icke-känsligt exempel och utvärdera det aktuella HiNoter-arbetsflödet endast inom verifierat beteende.
Styr åtkomst, lagringstid och ändringar
Det användbara testet här är samlingens omfattning, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter.
Arbetsregel: Styrning av åtkomst, lagringstid och ändringar godkänns när källan är länkad. Den misslyckas väsentligt när sammanfattningen blir den slutgiltiga sanningen. Håll samlingens omfattning, postens schema, metadata, källänkar, behörigheter, versionshantering, lagringstid och hämtningsuppgifter synliga, eftersom en välformulerad mening inte kan tillhandahålla bevis för något som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem. I scenariot Kundhistorik granskar du godkänd kontext och tillämpar åtkomstgranskning som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att betrakta en modells säkerhet som ett godkännande.
Beslut för det här avsnittet: bygg en möteskunskapsbas kring deklarerade hämtningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om källkedjan bryts börjar du med en avgränsad samling, dokumenterar policy och ägarskap och utökar först efter att tester av hämtning och korrigering har godkänts. Registrera vem som granskade posten och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om posten är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras live. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden för att bygga en möteskunskapsbas, inte en fotnot.

Bevisanteckning för guiden för att bygga en möteskunskapsbas: Granska Amazon Web Services — Amazon Transcribe Developer Guide (källdatum: 2026-01-20; typ: auktoritativ källa; roll: fakta / kontext / begränsning) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Bygg en sökbar möteskunskapsbas
Förbättra systemet
Följ misslyckade sökningar, inaktuella poster och korrigeringar som uppgifter i backloggen. Om vägen misslyckas, börja med en avgränsad samling, dokumentera policy och ägarskap och utöka först efter att hämtning och korrigeringstester har godkänts.
Testa hämtning
Ställ representativa frågor och granska källavsnitt och status. Behandla ett saknat fält som Ej tillämpligt i stället för som ett fördelaktigt antagande.
Läs in ett pilotmaterial
Läs in ett litet auktoriserat urval och granska varje post innan du utökar. Separera observerat beteende, dokumentation och redaktionell bedömning; blanda inte ihop deras etiketter.
Lägg till styrning
Fastställ regler för åtkomst, korrigering, lagring och ersättning tillsammans med policyägarna. Använd auktoriserat, icke-känsligt material och bevara tillräckligt med kontext för att kunna ifrågasätta ett resultat.
Definiera posten
Välj fält för mötesdatum, ämne, beslut, åtgärder, ansvariga och källor. Spara villkor, lokal, granskare och datum så att en annan person kan upprepa kontrollen.
Namnge hämtningsuppgifterna
Lista de frågor som människor behöver att kunskapsbasen besvarar. Det håller AI för möteskunskapsbaser kopplad till en observerbar indata och ett resultat.
Mät om kunskapen återanvänds
Det användbara testet här är samlingens omfattning, postens schema, metadata, källänkar, behörigheter, versionshantering, lagring och hämtningsuppgifter.
Arbetsregel: Mätningen av om kunskap återanvänds är godkänd när hämtningsuppgifterna är uttryckliga. Den misslyckas väsentligt när arkivet växer utan riktning. Håll samlingens omfattning, postens schema, metadata, källänkar, behörigheter, versionshantering, lagring och hämtningsuppgifter synliga, eftersom en välformulerad mening inte kan tillhandahålla bevis för något som mötet aldrig innehöll.
Använd det konkreta fallet: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem. I scenariot med Operations-wikin granskar du upprepningsbar policy och tillämpar aktualitetskontroller som den mänskliga gränsen. Läsaren ska kunna spela upp eller rekonstruera påståendet utan att behandla en modells konfidens som ett godkännande.
Beslut för detta avsnitt: bygg en möteskunskapsbas kring deklarerade hämtningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Om källkedjan bryts, börja med en avgränsad samling, dokumentera policy och ägarskap och utöka först efter att hämtnings- och korrigeringstester har godkänts. Anteckna vem som granskade objektet och om resultatet förblev ett utkast, korrigerades eller godkändes.
En andra kontroll förhindrar kategorifel. Fråga om objektet är ett faktum, en rekommendation, en olöst fråga eller ett produktbeteende som fortfarande behöver verifieras i praktiken. Den klassificeringen ändrar formuleringen, granskaren och nästa åtgärd; den är en del av guiden för att bygga en möteskunskapsbas, inte en fotnot.
Bevisanteckning för guiden för att bygga en möteskunskapsbas: Granska U.S. Federal Trade Commission — Keep your AI claims in check (källdatum: 2023-02-27; typ: auktoritativ källa; roll: fakta / kontext / begränsning) innan du förlitar dig på den relaterade standarden, funktionen eller metoden.
Omfattning och bevisetiketter
Tillhandahåller ett komplett arbetsflöde – från insamling av mötesdata till distribution, uppgiftsutförande och hämtning över flera möten – vilket minskar kopiering och inklistring, duplicerat innehåll och synkroniseringsfel.Metoden är en redaktionell operativ modell, inte ett påstående om att varje leverantör, språk eller möte fungerar på samma sätt.
Bevisetiketter som används här är Officiellt faktum, Reproducerad observation, Redaktionell rekommendation och Ej tillämpligt / overifierat. Kontrollera aktuella produktsidor, språkkonfiguration, integritetsvillkor, regional policy och det exakta urvalet igen före publicering.
Vanliga frågor: AI för möteskunskapsbaser
Hur bygger jag en möteskunskapsbas?
En AI-baserad möteskunskapsbas fungerar när posterna har stabil metadata, källänkar, styrning, granskningsstatus och hämtnings tester – inte bara volym. Tillämpa det svaret endast på de indata, roller, språk, villkor och granskningsregler som faktiskt har testats.
Vad bör jag verifiera först för AI för möteskunskapsbaser?
Börja med denna gräns: bygg en möteskunskapsbas kring deklarerade hämtningsuppgifter, stabila poster, källänkar, ägarskap, behörigheter och granskningsstatus Bevara källan, definiera de avgörande fälten och markera ej styrkt beteende som Ej tillämpligt innan du jämför välformulerade resultat.
Kan ett välformulerat AI-mötesresultat fortfarande vara fel?
Ja. Flyt mäter läsbarhet, medan trohet frågar om namn, siffror, negationer, talare, villkor, beslut, tidpunkt, terminologi och ton överensstämmer med källan. Granska dessa delar direkt.
Vilka bevis bör en granskare spara?
Spara beskrivningen av indata, källjudet eller transkriptet, resultatversionen, relevant tidsstämpel eller utdrag, granskarens beslut, korrigering och publiceringsstatus. Det gör det möjligt för en annan person att återskapa slutsatsen.
När bör automatisering avstå?
Automatisering bör avstå när ägarskap, beslutsstatus, kritiska entiteter, samtycke, källkontext, språkgränser eller målgruppens behörigheter inte kan fastställas. Märk objektet som olöst och skicka det till en ansvarig granskare.
Hur bör flerspråkiga eller rollkänsliga möten testas?
Använd representativa, auktoriserade urval; deklarera språk- eller roll etiketter; inkludera överlappande tal, namn, siffror, villkor och regionala varianter; och rapportera varje felklass separat i stället för att slå samman dem till ett enda poängtal.
Hur bör HiNoter utvärderas?
Kör en auktoriserad, icke-känslig version av detta fall: ett företag lagrar tusentals sammanfattningar men kan inte avgöra vilka beslut som fortfarande gäller eller vem som får korrigera dem. Verifiera aktuell indata, resultat, källnavigering, redigeringar, export, åtkomst och raderingsbeteende; lämna allt som inte testats som Ej tillämpligt.
Beslutsgräns
För ”Hur bygger jag en möteskunskapsbas?” är det försvarbara svaret fortfarande villkorat. En AI-baserad möteskunskapsbas fungerar när posterna har stabil metadata, källänkar, styrning, granskningsstatus och hämtnings tester – inte bara volym. en möteskunskapsbas blir tillförlitlig när människor kan hitta rätt post, förstå dess status, granska dess källa och korrigera den Om bevisen inte kan stödja ett påstående om AI för möteskunskapsbaser, publicera Ej tillämpligt eller inte verifierat i stället för en fördelaktig uppskattning.
Bygg en liten möteskunskapsbas: kör ett representativt urval, jämför resultatet med dess källa och testa HiNoter endast inom de exakta arbetsflödessteg som du verifierar.