W tym kompletnym autorskim przykładzie źródło ma jeden fragment. Pakiet zawiera pięć szkiców, ale newsletter nie ma treści. Poniższe wyniki pochodzą z istniejących funkcji narzędzi. To dane demonstracyjne, bez generowania przez AI i bez połączenia ze zdalnym klientem.
Potem kompletność pięciu tekstów
pomnoz_inspect_drafts zachowuje pustą treść. Zgłasza newsletter do uzupełnienia zamiast dopisywać zdania lub oznaczać tekst jako sprawdzony.
Pełne argumenty: jedno źródło i pięć autorskich szkiców
{
"result": {
"source": [
{
"id": "1",
"start": 0,
"end": 0,
"text": "Własny materiał: wybierz jeden przykład i sprawdź go przed publikacją."
}
],
"package": {
"posts": [
{
"title": "Jeden przykład",
"body": "Sprawdź jeden przykład przed publikacją.",
"sourceIds": [
"1"
]
},
{
"title": "Jak zacząć",
"body": "Wybierz przykład i porównaj tekst ze źródłem.",
"sourceIds": [
"1"
]
},
{
"title": "Pytanie",
"body": "Jaki przykład chcesz dziś sprawdzić?",
"sourceIds": [
"1"
]
}
],
"newsletter": {
"title": "Przykład w wiadomości",
"body": "",
"sourceIds": [
"1"
]
},
"article": {
"title": "Zacznij od przykładu",
"body": "Autorski szkic do sprawdzenia przed publikacją.",
"sourceIds": [
"1"
]
}
}
}
}
Wynik: pięć dokumentów i pusty newsletter
{
"total": 5,
"shown": 5,
"incomplete": [
"Newsletter — pusta treść"
],
"sourceNormalizationChanges": [],
"documents": [
{
"key": "post-0",
"label": "Post 1",
"title": "Jeden przykład",
"titleUtf16": 14,
"bodyUtf16": 40,
"missingTitle": false,
"missingBody": false,
"sourceIds": [
"1"
],
"editorialReview": "unknown_caller_supplied",
"factsVerified": null
},
{
"key": "post-1",
"label": "Post 2",
"title": "Jak zacząć",
"titleUtf16": 10,
"bodyUtf16": 45,
"missingTitle": false,
"missingBody": false,
"sourceIds": [
"1"
],
"editorialReview": "unknown_caller_supplied",
"factsVerified": null
},
{
"key": "post-2",
"label": "Post 3",
"title": "Pytanie",
"titleUtf16": 7,
"bodyUtf16": 36,
"missingTitle": false,
"missingBody": false,
"sourceIds": [
"1"
],
"editorialReview": "unknown_caller_supplied",
"factsVerified": null
},
{
"key": "newsletter",
"label": "Newsletter",
"title": "Przykład w wiadomości",
"titleUtf16": 21,
"bodyUtf16": 0,
"missingTitle": false,
"missingBody": true,
"sourceIds": [
"1"
],
"editorialReview": "unknown_caller_supplied",
"factsVerified": null
},
{
"key": "article",
"label": "Artykuł",
"title": "Zacznij od przykładu",
"titleUtf16": 20,
"bodyUtf16": 47,
"missingTitle": false,
"missingBody": false,
"sourceIds": [
"1"
],
"editorialReview": "unknown_caller_supplied",
"factsVerified": null
}
]
}
Na końcu zadeklarowane odwołania
pomnoz_inspect_bindings dla artykułu odnajduje fragment 1, ponieważ taki identyfikator podano w szkicu. Nie ocenia, czy zdania wynikają z tego źródła.
Pełne argumenty inspekcji artykułu
{
"result": {
"source": [
{
"id": "1",
"start": 0,
"end": 0,
"text": "Własny materiał: wybierz jeden przykład i sprawdź go przed publikacją."
}
],
"package": {
"posts": [
{
"title": "Jeden przykład",
"body": "Sprawdź jeden przykład przed publikacją.",
"sourceIds": [
"1"
]
},
{
"title": "Jak zacząć",
"body": "Wybierz przykład i porównaj tekst ze źródłem.",
"sourceIds": [
"1"
]
},
{
"title": "Pytanie",
"body": "Jaki przykład chcesz dziś sprawdzić?",
"sourceIds": [
"1"
]
}
],
"newsletter": {
"title": "Przykład w wiadomości",
"body": "",
"sourceIds": [
"1"
]
},
"article": {
"title": "Zacznij od przykładu",
"body": "Autorski szkic do sprawdzenia przed publikacją.",
"sourceIds": [
"1"
]
}
}
},
"documentKey": "article"
}
Wynik: odwołanie artykułu do fragmentu 1
{
"documentKey": "article",
"label": "Artykuł",
"title": "Zacznij od przykładu",
"total": 1,
"shown": 1,
"references": [
{
"id": "1",
"start": 0,
"end": 0,
"originalUtf16": 70,
"validatedUtf16": 70,
"normalizationChanged": false
}
],
"relationship": "caller_declared_only",
"semanticMatch": null
}
Sprawdź konkretną liczbę lub cytat.
Ten sam klient może wybrać cue: {field, kind, start, end}: title lub body, number lub quote i dokładne pozycje UTF-16. Początek włącznie, koniec wyłącznie; dla zamkniętego cytatu wskazujesz jego treść bez cudzysłowów. Schematy cytatów są takie jak w studio: „…”, “…” oraz proste i francuskie cudzysłowy. Niedomknięty cytat wskazuje znak otwierający, pusty — pozycję pustej treści. Wskazanie musi obejmować cały rozpoznany zapis w bieżącym polu. Po redakcji wyznacz pozycje ponownie; narzędzie nie przechowuje poprzedniej wersji tekstu.
W pełnym autorskim pakiecie briefu celowo dopisaliśmy do artykułu zdanie „Wynik wzrósł o 99%.”. To hipotetyczna zmiana do sprawdzenia, a nie wynik firmy lub działania AI. Poniżej trzy rzeczywiste odpowiedzi tego samego narzędzia:
- Dopisane 99%:
literal_absent. W przypisanym źródle nie ma takiej liczby. - 12 zapytań: również
literal_absent, bo oryginał zawiera słowo „dwanaście”. Narzędzie nie przelicza zapisu słownego. Taki wynik wymaga porównania przez redaktora, nie automatycznego usunięcia zdania. - Cytat o krótkim briefie:
literal_found w oryginalnym fragmencie 3. To dopasowanie tekstu, a nie dowód skuteczności briefu.
Pełne argumenty: pakiet briefu i dopisane 99%
{
"result": {
"source": [
{
"id": "1",
"start": 0,
"end": 0,
"text": "W naszym małym studiu projektowym przez ostatnie cztery tygodnie zapisaliśmy dwanaście zapytań. Pięć zawierało od razu cel, oczekiwany rezultat, termin i informację, co dostarczy zamawiający. W pozostałych siedmiu co najmniej jednej z tych informacji brakowało. To własne małe zestawienie, nie badanie branży. Nie mierzyliśmy czasu odpowiedzi, sprzedaży ani rentowności."
},
{
"id": "2",
"start": 0,
"end": 0,
"text": "Chcemy zacząć od czterech pytań. Po co powstaje materiał? Co konkretnie ma być oddane? Na kiedy jest potrzebne? Co jest już gotowe po stronie zamawiającego? Przy każdym punkcie zostawiamy możliwość odpowiedzi: jeszcze nie wiem. Niewiadoma ma być widoczna; nie zamieniamy jej automatycznie w założenie wykonawcy."
},
{
"id": "3",
"start": 0,
"end": 0,
"text": "Krótki brief nie ma opisać całego projektu. Ma pokazać, czy obie strony rozumieją ten sam rezultat. Po pierwszej odpowiedzi odsyłamy własnymi słowami zakres i listę otwartych kwestii. Dopiero po ich wyjaśnieniu potwierdzamy wycenę oraz termin. Na razie to plan do sprawdzenia. Nie wiemy jeszcze, czy zmniejszy liczbę wiadomości albo ułatwi sprzedaż."
},
{
"id": "4",
"start": 0,
"end": 0,
"text": "Nie chcemy robić formularza dłuższego niż sama rozmowa. Gdy zamawiający nie potrafi nazwać rezultatu, proponujemy krótką rozmowę i sami zapisujemy jej ustalenia. Cztery pytania są wspólną listą do rozmowy, a nie obowiązkowym testem klienta. Nasz dylemat: jak zebrać minimum potrzebne do decyzji i nie przerzucić całej pracy przygotowawczej na drugą stronę?"
}
],
"package": {
"posts": [
{
"title": "Siedem zapytań z niewiadomą",
"body": "W naszym małym zestawieniu z czterech tygodni tylko 5 z 12 zapytań miało od razu komplet czterech informacji: cel, rezultat, termin i materiały po stronie zamawiającego. W pozostałych siedmiu czegoś brakowało.\n\nTo nie statystyka rynku. Dla nas to sygnał, żeby przyjrzeć się początkowi rozmowy. Brak odpowiedzi na „co ma być oddane?” łatwo zasłonić własnym wyobrażeniem projektu. A wtedy obie strony mogą używać tych samych słów i oczekiwać czegoś innego.\n\nChcemy więc najpierw odesłać zakres własnymi słowami i nazwać niewiadome. Dopiero po ich wyjaśnieniu potwierdzać wycenę i termin. To plan do sprawdzenia — jeszcze nie wynik wdrożenia.",
"sourceIds": [
"1",
"3"
]
},
{
"title": "Cztery pytania przed potwierdzeniem zakresu",
"body": "Nasza robocza lista na początek rozmowy o projekcie:\n\n1. Po co powstaje materiał?\n2. Co konkretnie ma być oddane?\n3. Na kiedy jest potrzebne?\n4. Co jest już gotowe po stronie zamawiającego?\n\nPrzy każdym pytaniu dopuszczamy „jeszcze nie wiem”. Taka odpowiedź zostaje na liście do wyjaśnienia, zamiast po cichu zamieniać się w założenie wykonawcy.\n\nNastępny krok: zapisujemy zakres własnymi słowami, odsyłamy go wraz z otwartymi kwestiami i dopiero po wyjaśnieniach potwierdzamy wycenę oraz termin.\n\nLista ma pomóc w rozmowie. Jeśli druga strona nie umie nazwać rezultatu, rozmawiamy i sami zapisujemy ustalenia.",
"sourceIds": [
"2",
"3",
"4"
]
},
{
"title": "Brief pomaga czy przerzuca pracę na klienta?",
"body": "Chcemy zebrać minimum potrzebne do decyzji, ale nie robić formularza dłuższego niż sama rozmowa.\n\nJest tu napięcie: bez nazwanego rezultatu trudno potwierdzić zakres. Z drugiej strony zamawiający może właśnie potrzebować pomocy w jego nazwaniu. Kolejne obowiązkowe pole nie rozwiąże tej sytuacji.\n\nDlatego nasze cztery pytania traktujemy jako wspólną listę do rozmowy, a nie test, który klient musi zdać sam. Gdy rezultat pozostaje niejasny, proponujemy rozmowę i bierzemy na siebie zapis ustaleń.\n\nGdzie w Waszym procesie kończy się pomocne doprecyzowanie, a zaczyna przerzucanie przygotowania projektu na drugą stronę?",
"sourceIds": [
"2",
"4"
]
}
],
"newsletter": {
"title": "Nie dopowiadajmy sobie zakresu",
"body": "Cześć,\n\nw ostatnich czterech tygodniach zapisaliśmy w naszym małym studiu 12 zapytań. Pięć zawierało od razu cel, oczekiwany rezultat, termin i informację o materiałach zamawiającego. W siedmiu co najmniej jednego elementu brakowało.\n\nNie badaliśmy rynku ani wpływu briefu na sprzedaż. To mała obserwacja z własnej pracy. Skłoniła nas do ułożenia prostszego początku rozmowy.\n\nChcemy zacząć od czterech pytań: po co powstaje materiał, co oddajemy, na kiedy jest potrzebne i co jest już gotowe. Przy każdym zostawiamy miejsce na „jeszcze nie wiem”. Niewiadoma ma być wspólna i widoczna, zamiast stawać się ukrytym założeniem wykonawcy.\n\nPotem odsyłamy zakres własnymi słowami i listę otwartych kwestii. Dopiero po ich wyjaśnieniu potwierdzamy wycenę oraz termin.\n\nJest jednak granica: nie chcemy zamieniać rozmowy w egzamin dla klienta. Jeśli ktoś nie potrafi nazwać rezultatu, proponujemy rozmowę i sami zapisujemy ustalenia. Lista czterech pytań ma wtedy prowadzić obie strony.\n\n„Krótki brief nie ma opisać całego projektu. Ma pokazać, czy obie strony rozumieją ten sam rezultat.”\n\nTo zasada, którą chcemy sprawdzić. Nie mamy jeszcze dowodu na mniej wiadomości lub łatwiejszą sprzedaż. Na początek zależy nam na tym, by nie mylić wspólnych ustaleń z własnymi domysłami.",
"sourceIds": [
"1",
"2",
"3",
"4"
]
},
"article": {
"title": "Krótki brief: wspólny rezultat zamiast ukrytych założeń",
"body": "Krótki brief ma pomóc ustalić, co obie strony rozumieją przez rezultat projektu. Nie musi z góry opisywać całej pracy. W naszym małym studiu układamy taki początek rozmowy wokół czterech pytań i jawnej listy niewiadomych.\n\nCo pokazało małe zestawienie\n\nPrzez cztery tygodnie zapisaliśmy 12 zapytań. Pięć zawierało od razu cel, oczekiwany rezultat, termin oraz informację, co dostarczy zamawiający. W siedmiu co najmniej jednej z tych informacji brakowało.\n\nTo obserwacja z naszego studia, nie badanie branży. Nie mierzyliśmy czasu odpowiedzi, sprzedaży ani rentowności. Nie można na tej podstawie przypisać nowemu briefowi efektów, których jeszcze nie sprawdziliśmy.\n\nCztery pytania i dozwolona niewiadoma\n\nNasza robocza lista obejmuje: po co powstaje materiał, co konkretnie ma być oddane, na kiedy jest potrzebne i co jest już gotowe po stronie zamawiającego.\n\nPrzy każdym punkcie dopuszczamy „jeszcze nie wiem”. To istotny element procesu: brak danych pozostaje kwestią do rozmowy. Nie zostaje automatycznie uzupełniony wyobrażeniem wykonawcy.\n\nOd odpowiedzi do potwierdzonego zakresu\n\nPo pierwszej odpowiedzi chcemy odesłać zakres własnymi słowami wraz z otwartymi kwestiami. Dopiero po ich wyjaśnieniu potwierdzać wycenę i termin.\n\nZapis nie ma zastąpić rozmowy. Ma pokazać, czy strony rozumieją ten sam rezultat. Jeśli opis wymaga wyjaśnienia, to właśnie jest sprawa do ustalenia przed potwierdzeniem.\n\nLista do rozmowy, nie egzamin dla klienta\n\nNie chcemy tworzyć formularza dłuższego niż rozmowa. Zamawiający może potrzebować pomocy w nazwaniu rezultatu. Wtedy proponujemy rozmowę i sami zapisujemy ustalenia. Cztery pytania stają się wspólną listą, a nie obowiązkiem przygotowania projektu po drugiej stronie.\n\nCo pozostaje do sprawdzenia\n\nTen sposób pracy jest planem. Nie wiemy jeszcze, czy ograniczy liczbę wiadomości albo ułatwi sprzedaż. Jego punkt wyjścia jest skromniejszy: widoczna niewiadoma i zakres zapisany własnymi słowami mają zastąpić ciche dopowiadanie sobie projektu.\n\nWynik wzrósł o 99%.",
"sourceIds": [
"1",
"2",
"3",
"4"
]
}
}
},
"documentKey": "article",
"cue": {
"field": "body",
"kind": "number",
"start": 2010,
"end": 2013
}
}
Wybór trzech wskazań w tym samym pakiecie
{
"addedNumber": {
"documentKey": "article",
"cue": {
"field": "body",
"kind": "number",
"start": 2010,
"end": 2013
}
},
"spelledNumber": {
"documentKey": "article",
"cue": {
"field": "body",
"kind": "number",
"start": 287,
"end": 289
}
},
"exactQuote": {
"documentKey": "newsletter",
"cue": {
"field": "body",
"kind": "quote",
"start": 981,
"end": 1080
}
}
}
Rzeczywisty wynik: brak liczby, zapis słowny i dokładny cytat
{
"addedNumber": {
"field": "body",
"kind": "number",
"start": 2010,
"end": 2013,
"literalUtf16": 3,
"status": "literal_absent",
"sourceMatches": [],
"coordinates": "original_utf16",
"comparison": "exact_literal_only",
"manualReviewRequired": true,
"factsVerified": null,
"semanticMatch": null
},
"spelledNumber": {
"field": "body",
"kind": "number",
"start": 287,
"end": 289,
"literalUtf16": 2,
"status": "literal_absent",
"sourceMatches": [],
"coordinates": "original_utf16",
"comparison": "exact_literal_only",
"manualReviewRequired": true,
"factsVerified": null,
"semanticMatch": null
},
"exactQuote": {
"field": "body",
"kind": "quote",
"start": 981,
"end": 1080,
"literalUtf16": 99,
"status": "literal_found",
"sourceMatches": [
{
"id": "3",
"start": 0,
"end": 99
}
],
"coordinates": "original_utf16",
"comparison": "exact_literal_only",
"manualReviewRequired": true,
"factsVerified": null,
"semanticMatch": null
}
}
Każde wywołanie sprawdza jedno wskazanie. sourceMatches podaje pierwsze dopasowanie w każdym przypisanym fragmencie: id, start i end. Pozycje liczą oryginalne białe znaki, także na brzegach; tekst nie jest przycinany na potrzeby porównania. Narzędzie nie zwraca całych treści, nie dopisuje źródeł i zawsze pozostawia manualReviewRequired: true.