DEV Community: Luna

Different Saju Results? Match the Input Before the Comparison

Luna — Wed, 16 Sep 2026 05:00:11 +0000

For AI human review, the first decision is whether one small example can be reviewed by a person. The same birthday on different saju screens is not enough to establish that the inputs match. Before comparing results, record the calendar selection, birth time, location-related settings, and any calculation options the demos expose. Compare the underlying chart separately from the written interpretation. Matching results show agreement on that case; they do not establish calculation accuracy.

Match the conditions: use a fictional birthday and preserve every selected setting.

Separate the outputs: compare chart fields before comparing interpretation text.

Limit the conclusion: record agreement, disagreement, or uncertainty without declaring a calculator correct.

This field-test worksheet is prepared on 2026-09-08. Tested date: not available. The supplied evidence contains no completed demo comparison, captured birth inputs, or resulting charts. The conditions below are a reproducible test plan, and the result cells remain unobserved.

The birthday is only the beginning of the record

“Same birthday” describes what a person remembers entering. A useful comparison needs a record of what each interface actually accepted.

A calendar selector, a time field, and an advanced-settings panel belong in that record. If a demo presents a conversion or adjusted value after submission, preserve that too. The submitted value and the displayed value are separate evidence.

For this exercise, call the interfaces Demo Alder and Demo Birch. These are fictional labels, not reviewed products. Use a fictional birthday rather than personal information.

The aim is narrow: establish whether the available evidence supports a meaningful comparison. It is not a test of whether an interpretation describes someone convincingly.

A shared birthday is a starting point, not a complete comparison record.

Put the input contract on the page

The following table is the reusable artifact. Copy it into an existing text document or spreadsheet; the worksheet requires no purchase. Access conditions for any demo remain a separate question.

Replace bracketed entries before running the comparison. Reuse the same fictional date and exact clock time wherever those fields are supported. Do not treat blank cells as matching values.

Condition	Fictional case to prepare	Demo Alder receipt	Demo Birch receipt
Entered birth date	[YYYY-MM-DD], explicitly fictional	Not observed	Not observed
Calendar selection	[Exact calendar label]	Not observed	Not observed
Leap-month selection	[Selected value or not applicable]	Not observed	Not observed
Birth time	[HH:MM], with format recorded	Not observed	Not observed
Time certainty	Known synthetic time; avoid an unknown-time default	Not observed	Not observed
Birthplace, if requested	[Same selected place]	Not observed	Not observed
Timezone setting, if exposed	[Exact label or offset]	Not observed	Not observed
Clock adjustment, if exposed	[Exact option and selected value]	Not observed	Not observed
Date-boundary convention, if documented	[Quoted setting label or documentation reference]	Not observed	Not observed
Other required selectors	[Field labels and selected values]	Not observed	Not observed
Submitted or converted values shown	Capture separately from entered values	Not observed	Not observed
Demo revision and capture date	Record whatever version information is available	Not observed	Not observed

This is an inspection list, not a claim that every demo implements these options or that every option changes every output.

Use “not exposed” when a control cannot be found. Use “undocumented” when its behavior cannot be established from the available explanation. Those labels preserve uncertainty; neither means “same as the other demo.”

Artifact caption: Input-condition worksheet for a fictional birthday. The receipt columns are unobserved because no demo captures accompany this article.

Capture what survived submission

Begin with a fresh input form. Enter the fictional case, inspect the selected settings, and capture the form before submission. Then preserve the result screen and any summary of the accepted inputs.

This creates a trace from intended values to submitted values to displayed output.

If the result screen omits the input summary, retain the form capture alongside it. Record that the result itself does not confirm the accepted values. Avoid reconstructing settings later from memory.

For a developer evaluating a source package, this trace is useful evidence of what the demo makes inspectable. It does not establish how the underlying implementation handles a setting that the interface hides.

Choose a straightforward baseline before exploring ambiguous or boundary-sensitive cases. That is a recommendation for easier diagnosis, not a claim that any baseline has passed here.

Compare the chart before the prose

Keep the output record separate from the input table. Otherwise, “different result” can become an untidy mixture of a changed selector, a changed chart, and a differently worded paragraph.

Output layer	What to preserve	What the comparison can establish
Accepted-input summary	Exact displayed date, time, and calendar information	Whether the displayed inputs agree
Core chart	Corresponding year, month, day, and hour fields, where shown	Whether those displayed fields agree
Additional calculations	Field labels, values, and available definitions	Whether comparable named outputs agree
Written interpretation	Relevant passages linked to the displayed chart	Whether the wording or stated interpretation differs
Warnings and omissions	Unknown-time notices, missing fields, validation messages	What limits the comparison

Preserve original labels before mapping fields across interfaces. Similar placement is not sufficient evidence that fields mean the same thing.

If the charts match while the prose differs, record that exact finding. Do not turn a writing difference into an alleged calculation defect. If the charts differ, identify the affected fields before speculating about the explanation.

Different prose and different chart values are different findings.

Change a condition only after saving the baseline

Once the baseline receipts are complete, duplicate the case and change a single exposed condition. Keep the remaining recorded inputs fixed.

A calendar selector is a possible variable if both interfaces provide it. An unknown-time option is another possible variable. These are proposed checks, not observed failures.

For every variation, record:

The field changed and its previous and new values.
The input summary displayed after submission.
The output fields that changed or remained unchanged.
Any warning, rejected submission, or missing result.
The settings whose behavior remains unknown.

Changing a selector while keeping the typed date fixed tests the response to that selector. It does not necessarily preserve the same intended birth event. State which comparison you are attempting.

If several conditions change together, preserve the result but mark the cause unresolved.

Agreement is a smaller claim than accuracy

Suppose a future run produces matching chart values. The supported conclusion would be: these interfaces displayed matching values for this recorded case under the visible conditions.

That would not establish independent correctness. Agreement leaves open whether the implementations use the same assumptions or share a mistake.

A stronger calculation check needs an independently justified expected result, with the relevant conventions stated. No such reference calculation is supplied here. Nor would a correct calculation establish that a written prediction is true.

Human review should therefore inspect the evidence trail, not reward an interpretation for sounding personally convincing. Whether interpretation text is AI-generated or otherwise produced, its fluency is not a calculation receipt.

Agreement is evidence of consistency; accuracy needs a justified reference.

Leave missing evidence visible

There is no verified failed submission, mismatched chart, or successful comparison to report in this article. Inventing one would defeat the worksheet’s purpose.

The present limitation is specific: there are no captured demo inputs and outputs from which to draw a test conclusion. Hidden settings, unclear field definitions, and missing input summaries are potential obstacles to document during a future run, not defects already observed.

The final decision is to use this worksheet as a prerequisite for comparing demos. A matched, documented case can support a bounded consistency finding. An undocumented case should remain unresolved.

Use the worksheet alongside the source-pack page to assess the linked demo and its stated installation conditions.

Related build logs

First AI SOP Template: Put the Failed Example First

TL;DR: Match and capture the input conditions, compare chart fields separately from prose, and treat matching results as agreement rather than proof of accuracy.

The next episode examines what a useful reference case needs before it can support a calculation check.

Continue with the dated source map, related beginner guides, and current limits on Builderlog
Start with the free decision tools. Inspect the scope and evidence before choosing any paid next step.

Source Pack Pricing: Check Running Costs Before Buying a Digital Product

Luna — Wed, 16 Sep 2026 05:00:05 +0000

For digital product pricing strategy, the first decision is whether one small example can be reviewed by a person. A source pack’s purchase price does not establish what you will need to pay to run it. Before buying, extract the account, hosting, and external-service requirements from its public installation guide. Separate required dependencies from optional additions, and leave unsupported charges marked unverified.

Required: document what the intended installation needs, then verify whether it creates a charge.

Optional: separate additions that the documented basic setup can run without.

Unverified: keep missing requirements, billing terms, and usage assumptions visible.

That is the answer to “What do I pay beyond the source pack?” The amount depends on documented execution conditions and applicable billing terms. Without those receipts, a total would be a guess.

The useful first action happens before checkout

Start with a document review that requires no purchase: read the publicly accessible installation instructions. If they are unavailable, record that gap rather than treating a product description as an installation guide.

Define the result you want before collecting costs. Running a package locally, putting it online, and operating it for customers are different scopes. A cost table becomes misleading when it quietly moves between them.

Write a short scope statement:

Intended use: [describe the result]. Installation target: [local or hosted]. Needed features: [list]. Excluded features: [list].

Then look for prerequisites, account creation, deployment instructions, configuration variables, external connections, and limitations.

The aim is not to predict every possible expense. It is to identify the dependencies between buying the files and reaching your intended result.

A required account is not proof of a required subscription.

The evidence stops short of a cost estimate

Prepared: 2026-09-08.

Tested date: unavailable; no execution test is evidenced in the supplied facts.

Conditions: this is a document-review method, without verified service prices, usage measurements, or buyer execution results.

The supplied verified facts contain no operating-cost data. They therefore support neither a monthly estimate nor a claim that a particular installation runs without additional charges.

That limitation matters. An empty amount field should remain empty. Replacing it with “free,” “included,” or “probably negligible” would turn missing evidence into a purchasing claim.

The concrete artifact here is the worksheet below. It is a reusable evidence record, not a completed audit of a particular source pack. Its rows are categories to investigate, not claims that every package requires those services.

A completed version needs installation excerpts and applicable billing terms attached to its entries. Until then, the honest conclusion is that the additional amount remains undetermined.

Build the table around requirements, not guesses

Use separate fields for the dependency and its price. A component can be required while its charge remains unverified. An optional feature can still become expensive if you enable it.

Candidate cost item	Requirement status	Cost status	Receipt needed
Account used for installation	Unverified until the guide establishes it	Unverified	Account prerequisite and applicable billing conditions
Hosting for the intended deployment	Required if the documented target needs it	Unverified	Supported deployment path and matching plan terms
Data storage	Required if the basic execution path depends on it	Unverified	Storage setup instructions and charging basis
External service connection	Required if a needed feature depends on it	Unverified	Feature dependency, credential instructions, and usage terms
Custom domain	Optional if the documented basic setup works without it	Unverified	Basic-address support and domain billing terms
Monitoring or backup additions	Optional only if the basic setup does not require them	Unverified	Installation scope and add-on terms
Installation help	Optional if self-installation is supported and suitable	Unverified	Included support boundaries and any separate service terms

For the finished cost sheet, retain only relevant rows. Add package-specific dependencies when the documentation supports them.

Do not label something optional merely because it sounds like an enhancement. If the intended result depends on it, it belongs in the required group for your scope.

Likewise, “unverified” should not become a miscellaneous bucket. Specify what is missing: necessity, price, billing unit, eligibility, or usage.

Follow the installation path into the billing conditions

Work through the guide in its documented order. Each time it asks you to create an account, provision a resource, supply a credential, or enable an integration, capture the exact instruction and its location.

Then connect that instruction to the feature it supports. This prevents an optional integration from being mistaken for a prerequisite—and prevents a required dependency from disappearing into a footnote.

For each dependency, record:

The installation excerpt and document location.
The feature or execution stage that needs it.
Whether an alternative is explicitly supported.
The applicable pricing source and date checked.
The billing unit and any conditions still unresolved.

A configuration variable alone does not establish whether a paid service is mandatory. Look for an explanation of when the variable is used and what happens without it. If the guide does not answer, preserve the uncertainty.

Check pricing against the actual resource named in the instructions. A general pricing headline is not enough to establish the terms of the intended setup.

Required tells you what the software needs; verified tells you what the evidence supports.

A free allowance still needs a matching workload

Treat any advertised free allowance as a conditional billing term.

Record what it covers, who qualifies, whether billing details are required, and what happens when the allowance is exceeded. Also check whether the stated terms apply to the intended use.

Do not infer that a package fits within an allowance simply because the project is small. Without measured or otherwise supported usage, that fit remains unverified.

Keep the distinctions explicit:

Documented allowance: the published terms describe an allowance.

Applicable allowance: the intended account and use meet its conditions.

Workload fit: evidence shows the intended usage stays within it.

These are separate claims. Evidence for the first does not establish the others.

The same discipline applies to an existing subscription. Record any supported entitlement, but do not assume it covers a new deployment or its incremental usage.

The missing receipt is a decision input

No verified failed installation or unexpected bill is supplied here. The failure modes below are review risks, not reported incidents.

A demo can show visible behavior while leaving buyer-side account requirements unresolved. A successful local launch can leave hosted billing unresolved. A purchase description can explain file delivery while leaving installation support unclear.

The practical response is to connect each claim to the evidence that can establish it. Use the installation guide for prerequisites, billing terms for charges, and execution evidence for whether the documented path works under stated conditions.

Do not make any receipt answer a question it does not cover.

Keep this checklist beside the purchase decision

[ ] Define the intended execution result.
[ ] Save the public installation guide’s location and revision, if available.
[ ] Extract required accounts, resources, and service connections.
[ ] Separate optional features using documented dependencies.
[ ] Attach applicable billing terms to each relevant row.
[ ] Mark missing amounts and usage assumptions unverified.
[ ] Identify which unresolved item could change the buying decision.

Final decision: review the public installation guide before committing to the package. Proceed only when the required dependencies and remaining uncertainty fit your budget and installation ability. If a necessary service lacks usable billing evidence, the cost review is incomplete.

Related build logs

Check AI Product Translation Against the Source Before Publishing

TL;DR: Separate source pack pricing from execution requirements: classify dependencies, attach billing receipts, and keep unsupported running costs unverified.

The next episode examines how to compare included installation support with the work a buyer must handle.

Decide What to Buy When Project Scope Changes

Luna — Tue, 15 Sep 2026 05:00:12 +0000

For AI project management workflow, the first decision is whether one small example can be reviewed by a person. “Could you add this too?” leaves a concrete problem: nobody knows whether the request corrects an existing promise or creates a new purchase. Put the request beside the original deliverable and its acceptance conditions before discussing a quote. For a finished software package, the first decision is whether the requested capability belongs in the purchase at all.

Existing scope: the request is necessary to meet an explicit promise.

Separate quote: the request adds a deliverable, and a seller must confirm that they offer it.

Needs clarification: the wording or supporting evidence cannot establish the boundary.

That is the useful role for AI in this project management workflow: organize the comparison for human review. An AI summary cannot establish what a seller promised, approve additional work, or turn a finished product into a custom development service.

The small request hides a buying decision

“Add an export” sounds modest. It might mean showing someone an existing download button. It might mean repairing a promised export. It might mean building a capability absent from the product.

Those interpretations produce different deliverables and acceptance conditions. Calling all of them “small changes” skips the decision that matters.

For a buyer evaluating a finished software source package, start with the documented package, demonstration, license, and installation conditions. A purchase can be appropriate even when it excludes something useful. The question is whether the included behavior meets the buyer’s actual need.

If an essential capability is missing, the choices include finding another package, planning buyer-owned implementation, or exploring a separately offered service. Additional payment does not automatically make the original seller available for development.

A request’s friendly wording does not tell you whether it belongs in the purchase.

The evidence boundary belongs on the page

Prepared: September 8, 2026.

Tested date: none supplied.

Conditions: an illustrative comparison using fictional promises and requests; no live customer exchange, inspected product, or verified acceptance result.

The supplied operating facts establish the preparation date. They do not establish that this workflow has been tested or has saved money, reduced disputes, or improved delivery. The table below is a reusable artifact, not a customer case study.

Its reasoning is inspectable because each proposed category sits beside the promise that would support it. That makes the assumptions visible without presenting them as real-world receipts.

For an actual buying decision, replace the fictional baseline with exact excerpts and source locations. If the relevant evidence is missing, keep the classification provisional.

Put the promise beside the request

Consider a fictional convenience-store deals app source package. Its illustrative description includes filtering deals by store, provides installation instructions for a stated environment, and excludes account synchronization and seller-managed installation.

These are invented conditions for the worksheet. They describe no actual product or transaction.

Illustrative additional request	Baseline promise to verify	Proposed category	Deliverable consequence	Acceptance consequence
“Please make the store filter match the selected store.”	Store filtering is explicitly included.	Existing scope, if reproduction confirms the promised behavior is missing.	Correction to the included filter; no broader feature implied.	With controlled sample data, selecting a store shows its matching deals and excludes other stores’ deals.
“Please keep saved deals synchronized across devices.”	Account synchronization is explicitly excluded.	Separate quote, subject to an available offering.	Additional account and synchronization behavior would need its own specification.	Agree on saved-state behavior, supported access conditions, and conflict handling before estimating or accepting it.
“Please make installation easier.”	Instructions cover a stated environment; seller-managed installation is excluded.	Needs clarification.	Could mean correcting documentation, explaining a prerequisite, or requesting an additional service.	Identify the failing instruction, environment, expected result, and requested assistance before defining completion.

Comparison diagram caption: Each fictional request is traced from the original promise to its proposed category, changed deliverable, and acceptance condition.

The filter row remains conditional because the request alone does not prove a defect. Unexpected results could come from sample data, a local modification, or an unsupported environment.

The synchronization row describes a potential purchase boundary, not a service commitment. The installation row stays unresolved because “easier” does not identify an observable result.

Give AI a sorting job with traceable inputs

A recommended AI-assisted review starts with a bounded evidence packet: the original request, relevant product wording, documented exclusions, installation conditions, and any available reproduction evidence.

Keep the original request visible beside its summary. “Make installation easier” must not quietly become “provide remote installation.” Those are different requests.

For every proposed category, require a supporting excerpt or an explicit statement that the evidence is missing. The reviewer should be able to follow the reasoning without trusting the summary.

Then check the classification against the changed deliverable. If the row adds persistent user data, supported environments, external dependencies, or ongoing operation, those additions need explicit treatment.

Avoid accepting an effort estimate at this stage. Until the requested behavior and acceptance conditions are clear, an estimate can lend precision to an unresolved question.

An AI classification is useful when a reviewer can trace it back to the promise.

Change the acceptance condition before accepting the price

The buyer needs to know what “done” would mean before deciding whether an addition is worth purchasing.

Use this sentence pattern:

Under [agreed conditions], when [action occurs], the deliverable produces [observable result]. Evidence is [demonstration, file, or check]. Excluded behavior is [explicit boundary].

For the fictional filter, a demonstration with controlled data can make the expected behavior observable.

Synchronization needs more definition. A screen that displays saved deals does not establish how updates propagate or what happens when changes conflict.

Installation requires similar care. Corrected documentation and successful execution in a buyer’s environment are distinct deliverables. A quote should identify which result, if any, is being offered.

Keep the worksheet small enough to use

Copy this artifact into a document or spreadsheet. Completing it manually does not require purchasing a dedicated scope-management tool; any optional AI service has its own access conditions.

Scope change review

Request: Preserve the requester’s wording.
Existing promise: Paste the relevant excerpt and its source.
Conditions: Record supported environments, prerequisites, and exclusions.
Category: Existing scope / separate quote / needs clarification.
Reason: Explain what connects the request to the promise.
Deliverable change: Identify what would be added, corrected, or clarified.
Acceptance change: State the observable result and evidence required.
Open question: Name the missing fact preventing a decision.
Disposition: Included correction, optional purchase, clarification pending, or unavailable.
Approval: Record who accepted the boundary and which version they reviewed.

The limit is also the final decision

There is no verified failure receipt for this method in the supplied facts. The relevant risks are prospective: a summary could omit a condition, a reviewer could mistake an expectation for a promise, or a proposed category could be treated as authorization.

Preserving excerpts helps reviewers notice those problems. It does not resolve ambiguous wording or prove delivery.

The buying decision is therefore conditional: proceed when the documented package meets the essential need. Treat missing capabilities as explicit dependencies, and leave unclear requests unresolved until their acceptance conditions can be written.

“Separate quote” identifies a boundary; it does not promise that someone will cross it.

Before purchasing, use this worksheet to compare the product’s documented scope and installation conditions with the behavior you need.

Related build logs

Check minority feedback before trusting an AI survey summary

TL;DR: Compare each request with the original promise, identify the changed deliverable, and define acceptance before deciding whether anything additional should be purchased.

Next episode examines how to turn an unclear installation request into an acceptance condition a buyer can verify.

Evidence and scope

Evidence	What it supports	Boundary
Google Autocomplete, reviewed 2026-09-08	The exact query `AI project management workflow` appeared in the current suggestion surface	A query-surface signal only; not search volume, ranking, purchase intent, or an outcome
Synthetic editorial example	Shows the fields or decision path discussed here	Not a measured production result

Reviewed on 2026-09-08 under a synthetic editorial condition; no private data, external send, or production outcome was used.

Check minority feedback before trusting an AI survey summary

Luna — Tue, 15 Sep 2026 05:00:07 +0000

For AI research workflow, the first decision is whether one small example can be reviewed by a person. A survey summary can describe positive feedback while leaving a complaint with nowhere to go. To check for that problem, compare each response with the summary and look for its meaning, conditions, and requested change. Smooth prose is not evidence that every decision-relevant detail survived.

Why a complaint disappears: a summary organized around shared themes can omit an exception.

Why different requests merge: a broad label can hide incompatible preferences.

What to check: trace each response to a summary passage or mark it as missing.

This is a worked review exercise, not a reported experiment. Prepared on September 8, 2026; tested date: not established. No recorded AI run, measured result, or verified cost was supplied. The fictional responses and deliberately incomplete summary below make the comparison inspectable without presenting invented material as customer research.

The reassuring sentence that loses the problem

Imagine a fictional convenience-store deals app. Its survey asks what works and what should change.

The responses discuss browsing, notifications, and using offers at checkout. A proposed summary reads:

Feedback is positive about browsing and finding relevant deals. Respondents want better notifications and clearer offer information.

This is an illustrative summary, not a captured AI output. Its purpose is to expose what a reviewer should inspect when evaluating an actual AI-generated survey summary.

“Better notifications” sounds useful until the source material asks for incompatible changes. “Clearer offer information” sounds reasonable until a response describes an offer failing at checkout.

The question is whether the summary preserves enough information to support the next decision. A summary does not need to repeat every sentence. It does need to avoid changing what the evidence means.

A theme can survive compression while the problem inside it disappears.

Put every response beside the summary

The table contains fictional survey material created for this exercise. Letter labels identify responses; they are not participant records. The assessment applies only to the illustrative summary above.

Response	Fictional source text	What the illustrative summary preserves	Review finding
A	“The deal cards are easy to scan.”	Positive browsing feedback.	Meaning retained at a broad level.
B	“I like browsing offers by category.”	Positive browsing feedback.	Meaning retained; category detail omitted.
C	“The saved-offers page is easy to use.”	General positive browsing feedback.	Specific praise for saved offers is blurred.
D	“The offers usually match what I buy.”	Relevant deals.	Meaning retained.
E	“The pictures help me choose an offer.”	General positive browsing feedback.	The role of pictures is omitted.
F	“I can compare deals without getting lost.”	Positive browsing feedback.	Broad meaning retained; comparison detail omitted.
G	“An offer marked valid was rejected at checkout. I could not use it.”	Clearer offer information.	The failed use of an offer is missing.
H	“Notify me as soon as a saved item has a deal.”	Better notifications.	The request for immediate alerts is missing.
I	“Stop sending individual alerts. Let me receive a digest.”	Better notifications.	The digest preference and its conflict with immediate alerts are missing.
J	“Show the expiry before I save an offer; opening the details interrupts browsing.”	Clearer offer information.	The requested placement and browsing condition are missing.

Artifact caption: Response-by-response comparison of fictional survey answers with an illustrative summary. Each row identifies retained meaning or a specific omission.

The receipts here are the visible text pairs. A reader can inspect the checkout response and see that “clearer offer information” does not communicate a rejected offer. The notification responses visibly request different delivery patterns.

Those are observations about this constructed example. They do not establish how often an AI system makes these mistakes.

A missing detail is not always a missing decision

The table deliberately distinguishes broad retention from consequential loss.

The browsing praise is compressed. Depending on the research question, that may be acceptable. A brief overview might not need separate discussion of pictures, categories, and saved offers.

The checkout complaint deserves separate treatment because it describes an unsuccessful attempt to use the product. Recasting it as an information preference changes the nature of the report.

Likewise, immediate alerts and a digest belong under the same topic, but they should remain distinguishable. A shared heading does not establish agreement about the solution.

The placement request also matters. “Show the expiry” and “show the expiry before saving” imply different changes. Dropping the condition can leave a team solving a nearby problem.

The review standard is decision relevance. Preserve details that could change what someone investigates, builds, or prioritizes.

Keep opposing requests visible even when they share a topic.

Make the comparison reproducible

Start by preserving the original responses and the exact summary being reviewed. Keep them unchanged during the comparison so later edits remain distinguishable from the initial output.

Assign a stable label to each response. If a response contains separate ideas, record them separately under that label. Praise for browsing should not cancel a complaint about checkout in the same answer.

For each idea, locate the summary passage that represents it. Copy that passage into the review table. If there is no defensible match, write missing. Avoid supplying meaning that the summary itself does not express.

Then classify the relationship:

Retained: the summary preserves the meaning needed for the research question.
Broadened: the topic survives, but a relevant distinction is lost.
Merged: separate requests become a shared claim that obscures their differences.
Missing: the idea has no adequate representation.
Unsupported: the summary introduces a claim without a matching source.

Review complaints, opposing preferences, and conditional statements explicitly. This is a useful workflow for checking minority feedback because it makes coverage visible at the response level.

The comparison can be performed directly in a text document. No paid purchase is prescribed here, but there is no verified basis for calling an actual AI run free.

Repair the summary without inventing a conclusion

A more faithful version of the illustrative summary would read:

Positive comments concern browsing, relevance, and comparing offers. A separate response reports that an offer marked valid was rejected at checkout; the cause is unknown. Notification preferences differ between immediate saved-item alerts and a digest. Another request asks for expiry information before saving an offer.

This revision preserves distinctions without claiming that the checkout report has been independently confirmed.

It also stops short of choosing a notification design. Configurable delivery might be worth investigating, but that is a recommendation derived from the responses, not something the responses have validated.

For actual research, retain the response labels beside summary claims so a reviewer can return to the source.

The boundary of this field exercise

No real survey, captured AI summary, repeated trial, or observed failure rate accompanies this article. The constructed example demonstrates a review method; it cannot establish system reliability.

Coverage is also different from truth. Preserving a complaint accurately does not verify its cause. Preserving a preference does not establish how widely it is shared.

The final decision: treat an AI survey summary as reviewable draft material until its decision-relevant claims and omissions have been checked against the responses.

Use this checklist with the next summary you review:

[ ] Preserve the source responses and original summary.
[ ] Label responses and separate distinct ideas.
[ ] Match each idea to an exact summary passage.
[ ] Mark missing complaints and lost conditions.
[ ] Keep conflicting requests distinguishable.
[ ] Remove unsupported conclusions.
[ ] Preserve source labels in the revised summary.

Related build logs

AI Workflow for Beginners: One Manual First Run Before Automation

TL;DR: Check a survey summary against each response so minority complaints, conflicting requests, and important conditions remain visible.

The next episode examines how to carry conflicting feedback into a decision note without inventing consensus.

Evidence and scope

Evidence	What it supports	Boundary
Google Autocomplete, reviewed 2026-09-08	The exact query `AI research workflow` appeared in the current suggestion surface	A query-surface signal only; not search volume, ranking, purchase intent, or an outcome
Synthetic editorial example	Shows the fields or decision path discussed here	Not a measured production result

Reviewed on 2026-09-08 under a synthetic editorial condition; no private data, external send, or production outcome was used.

Check AI Product Translation Against the Source Before Publishing

Luna — Mon, 14 Sep 2026 05:00:13 +0000

Your AI-translated product description is ready to read, but are its dimensions and included items still faithful to the source? Start with a free human review: place the original beside the translation and compare each purchase-relevant fact. Treat readable prose as a draft until the numbers, units, contents, and exclusions have matching evidence.

Compare: Match each specification and purchase condition to its original wording.

Flag: Mark omissions, changed meanings, and unsupported additions.

Decide: Resolve material differences before approving the description.

This playbook supplies the review checklist. It does not report a completed translation test or a measured improvement.

The receipt begins with an honest boundary

Prepared: 2026-09-07.

Tested date: Not available; no completed translation test was supplied.

Conditions: No original listing, translated listing, product specification sheet, or customer response was available for inspection.

That boundary matters. There is no evidence here that a particular translation got a measurement wrong, omitted an accessory, or misled a buyer. Those are review targets, not observed failures.

The concrete deliverable is a reusable comparison sheet. A completed sheet becomes a receipt when it contains exact source excerpts, corresponding translated excerpts, and documented decisions. An empty checklist is a method, not proof that a product description passed.

There is also insufficient relevant evidence to judge recent changes or actual audience reactions. This article makes no trend claim about AI product translation.

Put the purchase facts beside each other

Begin with the original description and its translation. Keep their headings, specification tables, package contents, and footnotes visible. Record which product variant and source version you are reviewing.

Use the same variant throughout. If the original describes a compact version and the translation describes a larger version, stop and resolve that mismatch before editing sentences.

Build comparison rows around facts rather than paragraph boundaries. A translated paragraph may combine details that appeared in separate places in the original. The review should still account for each detail.

For every row, copy the exact source wording and the corresponding translated wording. Leave the translation cell blank if nothing matches. Do not silently supply missing information from memory.

Include facts from captions or package-content notes when they affect the offer. If relevant wording is embedded in an image, transcribe it into the sheet and note its location.

Comparison artifact caption: Original and translated product facts aligned by dimension, unit, included item, and purchase condition, with unresolved differences marked beside their source.

A translation review needs a trail from each purchase claim back to its source.

Numbers need their labels attached

Compare numerical strings character by character, then check what each number describes.

A matching value is not enough if “package width” has become “product width.” Likewise, dimensions need their axis labels. Preserve the relationship between length, width, height, diameter, and depth instead of assuming their order.

Check decimal separators, range markers, multiplication symbols, and qualifiers such as “approximately” or “up to.” Treat each as part of the specification.

Keep units attached to their values during review. If the translation introduces a unit conversion, flag it for separate calculation and rounding checks. Do not approve it merely because the converted value looks plausible.

Where a conversion cannot be verified, retain the original measurement and unit pending clarification. Avoid making the translated listing more precise than its source.

The practical question is: Would a reader choose the same size or assess the same fit from either version? If the answer depends on a guess, the row remains unresolved.

Package contents are part of the promise

Next, compare what arrives with the purchase.

Separate the main product, included accessories, optional accessories, and items shown only for illustration. Match each component and its quantity to an explicit statement in the original.

Watch the scope of exclusion wording. “Accessories sold separately” and “mounting accessory sold separately” describe different boundaries. The translation should preserve which item the exclusion applies to.

Do the same for dependency language. If the original says an accessory is required for use, retaining “sold separately” while dropping “required” leaves the buyer with less information.

An absence in the source is not permission to infer inclusion. If a photograph shows a stand but the written contents do not establish whether it ships, record a source question.

Illustrative example, not an observed result: A fictional storage case description says, “Removable divider sold separately.” Its fictional translation says, “Includes a removable divider.” The appropriate flag is changed meaning. Restore the separate-purchase condition, then check that no other sentence still promises inclusion.

Give each difference a useful name

Use these labels consistently:

Omission: A source fact or condition has no translated equivalent.
Changed meaning: The translation changes a value, relationship, item, or condition.
Overstatement: The translation strengthens a claim beyond what the source supports.
Source unclear: The original does not provide enough information to approve the wording.

A row may need multiple labels. A missing qualifier can be both an omission and an overstatement.

For an illustrative wording contrast, “helps resist splashes” should not become “waterproof.” The review does not establish which performance claim is physically correct. It establishes that the translated claim exceeds the supplied wording.

Keep stylistic preferences separate from factual defects. An awkward sentence may preserve the offer accurately. A polished sentence may change it. Resolve the purchase facts before refining the voice.

The strongest-sounding description is not necessarily the most faithful translation.

Copy this review sheet

Review record

Source description and version:
Translation and version:
Product variant:
Review date:
Reviewer:
Unresolved source questions:
Decision: hold / revise / approve

Review area	Exact source excerpt	Exact translation excerpt	Flag	Required correction or evidence	Status
Dimensions and axis labels
Values, ranges, and units
Product versus package measurements
Included items and quantities
Optional or separately sold items
Required accessories or dependencies
Compatibility and limitations
Performance claims and qualifiers

Release checklist

[ ] The source and translation describe the same variant.
[ ] Every measurement retains its value, unit, label, and qualifier.
[ ] Introduced conversions have been independently checked.
[ ] Included items and quantities match explicit source wording.
[ ] Separate-purchase and dependency conditions remain visible.
[ ] No translated claim exceeds the source.
[ ] Source ambiguities remain flagged until supporting evidence resolves them.
[ ] Corrected passages have been compared with the source again.

Close the differences before closing the review

After editing, revisit the flagged rows. Record the corrected wording and the evidence used to resolve each difference. Search the rest of the description for repeated versions of the same claim.

This method has limits. It cannot establish that the original specifications are accurate, confirm physical package contents, or resolve an ambiguous technical term without additional evidence. Source fidelity and product verification remain separate tasks.

No observed failure rate or customer outcome is available here. The final decision is therefore procedural: hold publication when an unresolved difference could change what the buyer expects to receive or use.

For your first review, copy the sheet and complete it against an original description and its translation.

Related build logs

TL;DR: Approve an AI product translation only after its measurements, contents, exclusions, and claims have traceable source matches.

Next episode examines how to handle a product description whose original wording is too ambiguous to approve.

Bazi Calculator API: Choose Hosted HTTP, Local MCP, or Source

Luna — Mon, 14 Sep 2026 05:00:07 +0000

A Bazi calculator API is not one category. For a public HTTPS request, compare the documented contracts at saju-api.pages.dev and Sazu Manse API. For a local tool, OpenFate BaZi MCP runs as a stdio process. For calculation code in your own runtime, jaeyeonling/saju-ts is a local TypeScript library. An owned Korean Saju source pack is a different purchase: it is a web-app starting point with buyer-owned deployment, not a hosted API or MCP. This comparison uses public documentation and repository metadata checked on 2026-09-06. No provider signup or API call was made.

What should you choose first?

Choose the boundary before comparing output names. Hosted HTTP is the fit when your application needs a remote request, a provider key, and a provider-defined schema. Local MCP is useful when an AI client can launch a local stdio server and call its tools. A local library gives your code direct ownership of the integration. An owned source pack starts further up the product stack: UI, application flow, and deployment decisions are yours to operate. If an existing backend only needs JSON, evaluate hosted HTTP first; if you need an owned Korean UI and brand and can operate Node and D1, evaluate the owned source route.

Click image to enlarge.

What do the hosted API documents actually establish?

The saju-api quickstart documents a REST calculation request at POST https://saju-api.pages.dev/api/v1/calculate. It shows an X-API-Key header and fields including year, month, day, hour, gender, and language; its documented example uses hour: -1 for an unknown birth hour and says lang defaults to ko. That is enough to classify it as a hosted HTTP integration candidate, while uptime, pricing, and compatibility with a particular Korean time convention remain separate questions.

The Sazu documentation is dated 2026-09-01. It describes a hosted calculate endpoint, birth fields, and a true-solar-time option. Its plan notes distinguish fixed sample profiles in the free sandbox from paid real birth calculation. Treat that as a plan and input boundary to verify with the provider; it does not settle how its semantics match another Bazi or Korean Saju implementation.

What is different about local MCP and library options?

The OpenFate README presents a local stdio MCP setup using npx -y @openfate/bazi-mcp and a calculate_bazi_chart tool. Its documented inputs include calendarType, timezoneId, and dayBoundaryMode. The useful decision fact is the transport: your MCP client launches a local process.

The saju-ts repository is a local TypeScript library, and its primary GitHub metadata reports an MIT license. That can make it relevant when you want code in your own runtime. You still need to inspect maintenance, integration surface, output behavior, and notices for your project. A local library is not a ready-made hosted API.

What should you record before choosing?

Use the selection checklist to record the answers instead of relying on a product name.

Input and time rules. List every required field. Check whether the docs mention timezone, true solar time, daylight saving, lunar conversion, or Korean-specific handling. Preserve documented distinctions such as an unknown hour: -1, a default lang: ko, and OpenFate's calendarType, timezoneId, and dayBoundaryMode; callers should not normalize them away. Missing documentation is an unknown, not permission to fill in a rule.

Access and cost. Separate API-key mechanics from plan limits. A free sandbox may be sample-only. Record paid requirements as documented and leave production totals unknown until you verify them. Do not turn a sample response into a benchmark.

Runtime and rights. Hosted HTTP moves the request boundary to a provider. MCP and libraries move more runtime work to your machine. An owned source pack moves deployment and configuration to the buyer. Record the license or commercial terms from the primary source and check privacy, legal, and third-party notices before using birth data.

What does a completed comparison look like?

The completed document comparison records the four public developer sources and the owned Korean Saju source boundary. Its decision is deliberately conditional: hosted HTTP needs provider access and plan review; local tools need runtime and integration review; an owned source pack needs buyer-owned deployment and product review. The document comparison itself is complete, while runtime execution remains outside its evidence.

Where can this comparison mislead you?

“Bazi,” “Saju,” and “Four Pillars” are related labels, not a promise of identical calculation or time handling. A REST field list, an MCP tool schema, and a TypeScript package description are different kinds of evidence. I did not rerun provider tests or measure accuracy or speed, and I did not verify any benchmark a provider page may advertise. The free Sazu path is described as sample-limited, while arbitrary real-birth calculation is documented as paid; do not assume another provider follows that model. Human review is still needed for privacy, legal, third-party, license, and production settings.

Before a production decision, write down the smallest test that can disprove your assumption. For a hosted API, that might be a schema review using documentation and a provider-approved sandbox. For a local MCP or library, it might be a clean install in a disposable project, followed by inspection of inputs and outputs. For an owned source pack, it might be a local run through the intended Korean birth-date flow before buyer-owned D1 and DNS configuration. Keep that test separate from a claim that the system is accurate or production-ready. The purpose is to expose missing fields, time-rule questions, license gaps, and data-handling work early.

If you need an owned Korean Saju web-app starting point, review the Korean Saju source pack.

Korean Saju Web App Source: Start Locally Before Cloudflare D1

Luna — Sun, 13 Sep 2026 05:00:13 +0000

If you are evaluating a Korean Saju web app source, begin with a local run. The delivered package uses Node.js 22.13 or newer, installs with npm ci, and starts with npm run dev. That local path uses an isolated Miniflare D1 binding. A public deployment is a separate buyer-owned Cloudflare setup: you still need your own D1 database, DB binding, database ID, Worker configuration, and DNS decision.

Answer first: run and inspect the package locally before creating any remote resource. The package includes the checked-in Drizzle migration and a local D1 path; its shipped wrangler.jsonc intentionally has an empty d1_databases array. Do not treat a local page as proof that a buyer's Cloudflare account or production domain is configured.

Building your own Korean Saju app? Review the available $99 one-project source license, scope, and install conditions →

What does the package include?

The source package is a starting point for a Korean traditional Saju four-pillars application. Its README documents Korean birth-date input, solar/lunar conversion, seasonal-boundary and true-solar-time correction, four pillars, five-elements balance, ten-god and hidden-stem readings, Korean name-study Hanja selection, anonymous share links, and optional D1 persistence. It has no paid AI API dependency.

The $99 product is a one-buyer, one-project source license. You may rebrand, modify, operate one end product, and charge that product's users. The license does not grant permission to resell or redistribute the raw source. Read the included LICENSE.md and THIRD_PARTY_NOTICES.md before operating a public service.

How do I run it locally?

Use the package root and a supported Node version:

npm ci
npm run dev

Open the exact URL printed by Vite. The package's predev script applies the checked-in Drizzle migration to the local database named saju-source-local through wrangler.local.jsonc. The DB binding is local and disposable; the first run creates .wrangler/. No Cloudflare account, remote database, domain, or paid AI service is needed for this local path.

After the page opens, the documented checks are:

npm run build
npm test
npm run selftest
npm run lint

selftest starts an isolated local server, checks the page, local D1 view counter, and anonymous share API, then shuts down. Treat these as package checks to run on your machine, not as a claim that every buyer environment has passed.

What changes for a Cloudflare D1 deployment?

The production database belongs to the buyer. First create it with Wrangler, then put the returned database name and UUID into the project's D1 configuration. Cloudflare documents that wrangler d1 create returns the binding and UUID to place in configuration; see the official D1 Wrangler command reference.

Create the buyer-owned database first:

npx wrangler d1 create your-saju-db

Copy the returned database name and ID into wrangler.jsonc. The shipped remote array is empty; the local config is the one that currently carries the migration directory. Add a buyer-specific entry like this, replacing every placeholder before deployment:

"d1_databases": [
  {
    "binding": "DB",
    "database_name": "your-saju-db",
    "database_id": "",
    "migrations_dir": "./drizzle"
  }
]

Then apply the migration, build, and deploy:

npx wrangler d1 migrations apply your-saju-db --remote
npm run build
npx wrangler deploy

The DB binding must be exactly DB, database_name must match the buyer's database, database_id must be the returned ID, and migrations_dir must point to ./drizzle for this package. Cloudflare's D1 migration documentation explains that migrations are applied against the selected database and that a binding can define the migration directory. Confirm the package's Drizzle layout and current Wrangler behavior before adding further migrations.

Cloudflare's D1 getting-started guide separates local and remote operations. A remote database is a real account resource with its own access, data, and possible charges. Choose the buyer's Worker name, account, region or jurisdiction needs, and custom domain or route deliberately. Add the buyer-owned DNS or route only after those details are known.

Runtime

Local: Node.js 22.13+ and Vite dev server.

Production: Confirm Node, Wrangler, account, and deployment access.

Database

Local: Local Miniflare D1, DB binding.

Production: Create buyer-owned D1 and set database_id.

Migration

Local: Checked-in Drizzle SQL applied by predev.

Production: Apply the intended migration to the selected remote DB.

Origin

Local: http://localhost:5173 while developing.

Production: Set the buyer's HTTPS origin and review metadata/share origin.

Domain

Local: None required.

Production: Configure buyer-owned route or custom domain and DNS.

Privacy

Local: Local sample stays in the local run.

Production: Review notices and production data handling with a person.

What should I review before going public?

Change the brand and copy in app/page.tsx, metadata and share origin in app/layout.tsx, and visual tokens in app/globals.css. Before real users arrive, review the privacy notice, Korean legal notices, third-party terms, and production settings. The README states that the browser calculates the chart locally, while the share route stores a redacted derived result and excludes birth date, birth time, birthplace correction, Hanja name, and per-character stroke data. Verify the implementation and write your own notices for the service you operate.

If you only need to learn the flow or build a prototype, use the public demo and the Cloudflare documentation, then build from scratch. The Korean Saju source pack is for a buyer who values a packaged starting point, documented source, and bounded one-project rights. It does not include custom installation, rebranding, DNS, hosting, legal review, or ongoing operations. If that matches your use case, review the license and the buyer-owned deployment steps before choosing the pack.

Sources

This article uses Cloudflare's official D1 Wrangler command reference, D1 migration documentation, and D1 getting-started guide, plus the delivered package's README.md, docs/KO_QUICKSTART.md, package.json, wrangler.jsonc, and checked-in migration files.

Before a Digital Product Launch, Check Whether Your Template Needs Its Creator

Luna — Sun, 13 Sep 2026 05:00:07 +0000

A template can look finished while leaving its buyer unable to tell what to enter, what to preserve, or whether the output is correct. Before a digital product launch, check the copy a buyer would receive: clear its example inputs, add fictional customer material, and follow only the included instructions. That makes the creator’s hidden knowledge easier to spot.

Clear: Remove sample inputs without deleting formulas, labels, or reference data.

Replace: Enter fictional material and compare the output with a written expectation.

Record: Log unexplained fields, broken calculations, and surviving examples with their locations.

This is a field-test protocol and reusable checklist, not a completed test report. Prepared on 2026-09-06; tested date: not available. No inspected template, execution record, or verified outcome was supplied. The conditions below define a test someone can reproduce; they do not establish that any file passed.

The polished example leaves a question unanswered

An example-filled template shows what a finished result might look like. It does not establish whether a buyer can produce that result independently.

The distinction matters when the file itself is the product. A creator may remember that an unlabeled cell expects a category, that a shaded column contains formulas, or that a dashboard needs a refresh. A buyer has the download and its documentation.

The useful question is therefore narrower than “Is this template good?”

Can someone replace the example material and complete the promised task using the delivered instructions?

For a fictional customer-project tracker, that task might be entering a project, choosing its status, and finding it in the relevant summary. Keep the test tied to that promise. Attractive formatting is worth reviewing, but it cannot settle whether the underlying task works.

A finished example is a demonstration; replacing it is a usability check.

Start with the file a buyer would receive

Use a disposable copy of the intended delivery package. Keep the original available for comparison, including its instructions and example output.

Write down the supported application, file format, required permissions, and any dependencies the seller declares. Record the actual test conditions beside them. If the supported environment is unspecified, log that uncertainty before troubleshooting.

Run the check with capabilities already available to you. There is no need to buy another service just to assemble a fictional brief. If suitable AI access is already available, it can help draft synthetic material. Otherwise, a manually written fixture can exercise the same fields. No cost result is established here.

Read the included instructions before editing. Identify which areas are:

Buyer inputs that should change.
Formulas or generated outputs that should remain intact.
Reference material required for calculations or selections.
Example content intended only to demonstrate use.

If those categories are indistinguishable, record the ambiguity. Do not quietly solve it with knowledge that the buyer would lack.

Clear the examples without dismantling the product

Remove values from documented input areas using the application’s content-clearing action. Preserve formatting, validation, and formulas where the instructions require them.

Deleting an entire sheet or column may damage dependencies. That can become a separate recovery test, but it should not replace the basic question of whether the intended reset procedure works.

Inspect the blank state before entering anything new. Look at summaries, charts, headings, and export previews. Search for distinctive text from the original examples.

A remaining example might be intentional guidance. It might also be hardcoded content pretending to be an output. Record where it appears and what the documentation says it should do.

Likewise, an empty-state error is an observation, not yet a diagnosis. Note the displayed message and the action that preceded it. The cause could be a missing guard, an unsupported environment, or an accidental deletion.

Suggested evidence caption: “Template copy after documented sample inputs were cleared; annotations identify remaining example text and visible empty-state messages.”

This caption belongs with an actual captured artifact. It is not evidence by itself.

Give the template a fictional customer it has never met

Prepare synthetic material outside the template so the expected result does not depend on the file being tested.

The following fixture is invented for this protocol. It is not a customer record or an observed result.

Input material	Intended check
Customer label: Cedar Parcel	The new label replaces the supplied example wherever customer identity appears.
Project: seasonal catalog refresh	A descriptive project title remains readable in the intended output.
Optional reference: left blank	The documented optional field can remain empty without an unexplained failure.
Status: a documented available choice	The record appears in the summary associated with that choice.
Notes: text containing punctuation and line breaks	The supported output preserves the meaning and remains legible.

Where the template uses different fields, adapt the fixture to its documented purpose.

AI-generated fictional material needs review before use. Check that it is internally consistent, clearly synthetic, and free of copied customer information. Its role is to provide unfamiliar inputs. It cannot establish what the template should calculate.

For calculations, write the expected relationship independently: changing an included input should change its dependent result; changing a descriptive note should not change an unrelated total. Use the template’s documented calculation rules to derive expected values during the actual test.

Unfamiliar inputs are useful only when the expected behavior is clear.

Keep the receipt next to the problem

Enter the fictional material using only the delivered instructions. Whenever progress requires a guess, record the question before investigating.

“Confusing” is difficult to fix. “The field labeled ‘basis’ does not identify an accepted unit or provide an example” gives the creator a concrete documentation problem.

Use this reusable log:

Location	Action and input	Expected behavior	Observed behavior	Evidence	Retest
Sheet, field, or output name	Exact edit performed	Documented rule or independent expectation	Literal result, or “not tested”	Screenshot or saved copy reference	Pending, resolved, or unresolved

Keep observations separate from explanations. An unchanged summary is observable. “The formula range excludes new entries” requires inspection before it becomes a finding.

Suggested comparison caption: “Documented expected output beside the output produced from the fictional fixture, with the relevant input and discrepancy marked.”

A checklist that survives the handoff

Copy this into the release review and attach evidence to each completed item:

[ ] Buyer-editable fields are distinguishable from formulas and reference data.
[ ] Required inputs explain their meaning and accepted format.
[ ] Optional fields behave as documented when left empty.
[ ] The documented reset preserves required calculations and validation.
[ ] Original example text is removed or clearly labeled as guidance.
[ ] Fictional inputs reach the correct summaries and exports.
[ ] Calculated outputs match independently established expectations.
[ ] Invalid entries receive understandable feedback where validation is promised.
[ ] Saving and reopening preserves the intended working state.
[ ] Each observed defect has a location, reproduction record, and retest status.

Decide what the evidence actually supports

No unexplained field, broken formula, or surviving example has been verified for this article. Those are inspection targets, not reported failures.

Even a completed self-check has limits. The creator still knows the product. Synthetic inputs may miss real workflows. A successful run in a recorded environment does not prove compatibility elsewhere or establish buyer satisfaction.

An untested checklist is preparation, not a passing result.

The decision is to use this check as a release gate: repair defects that block the promised task, explain necessary conditions, and repeat the affected actions. Keep untested behavior labeled as such.

Use the checklist on the exact template copy intended for delivery, and retain the completed log beside it.

Related build logs

TL;DR: A template’s readiness depends on whether fresh inputs produce the promised result with documented instructions—and whether the test leaves inspectable evidence.

The next episode examines how to turn a template’s setup assumptions into instructions a buyer can follow independently.

Evidence and scope

Evidence	What it supports	Boundary
Google Autocomplete, reviewed 2026-09-06	The exact query `digital product launch checklist` appeared in the current suggestion surface	A query-surface signal only; not search volume, ranking, purchase intent, or an outcome
Synthetic editorial example	Shows the fields or decision path discussed here	Not a measured production result

Reviewed on 2026-09-06 under a synthetic editorial condition; no private data, external send, or production outcome was used.

Start Your Beginner AI Project With the Deliverable File

Luna — Sat, 12 Sep 2026 05:00:15 +0000

“Finish my first AI project” leaves the most useful detail blank: the file someone should receive. Start by naming that deliverable in a free document, then add its reviewer, deadline, and completion evidence. Use AI to help produce the file, check it against the source, and record the handoff before marking the task complete.

Deliverable: Name the file and explain what its recipient needs to do with it.

Review: Assign someone to check its contents against explicit acceptance conditions.

Completion: Keep the final file, the review decision, and evidence that the recipient can access it.

That is the starting point for this beginner AI project management playbook. Keep the workflow small enough to review directly. Leave paid-tool selection until you have a checked result and a specific limitation to investigate.

The task starts with something you can hand over

“Use AI for marketing” describes an area of interest. “Create an approved announcement document from the supplied event notes” describes a deliverable.

The second statement gives the work an edge. There is an input, an output, and someone who can judge whether the output is usable.

For a first project, choose a real task whose source material you can understand yourself. Suitable possibilities include an internal announcement, a meeting summary, or a comparison sheet built from supplied information.

Avoid choosing a task simply because the demonstration looks impressive. If you cannot check the result, simplify the assignment until you can.

Write the filename before opening a conversation with an AI assistant. Then write what belongs inside it and what falls outside the assignment.

A useful project starts with a file someone can inspect.

Put the agreement in a free document

Use a free document you can already create and edit. This is a recommendation about keeping the assignment simple, not a verified comparison of software prices or features.

The document serves as your work sheet. It holds the agreement about what will be delivered, along with the evidence needed to close the task.

Here is an invented example, not a completed project or a reported result:

Field	Example entry
Reader need	Event volunteers need an announcement they can distribute after approval.
Deliverable	`event-announcement.md`
Contents	Event purpose, location, schedule, and registration instructions supported by the supplied notes.
Source	The event coordinator’s approved notes.
Reviewer	The event coordinator.
Deadline	Enter the agreed delivery date and time before starting.
Acceptance	Required details match the source; missing information is flagged; the file opens correctly.
Completion evidence	Final file location, reviewer decision, and access confirmation.
Boundary	Preparing the announcement does not authorize publishing or sending it.

The deadline remains blank here because no actual agreement has been supplied. In your working copy, replace it with a real commitment.

If you are also the recipient, assign yourself the reviewer role explicitly. That records who owns acceptance; it does not make the review independent.

Give AI a bounded part of the work

With the work sheet written, decide which production task AI should help with.

For the fictional announcement, that might mean organizing approved notes into readable paragraphs. The human responsibility remains checking whether the resulting announcement accurately represents those notes.

Keep source material separate from draft material. Label unresolved details where you can see them. A missing location should remain an open question until an authorized person supplies it.

Review the draft before investing effort in presentation. Ask whether each required detail is present, whether each factual statement has support, and whether the intended recipient can act on the document.

When something needs correction, describe the specific mismatch. “The registration instructions omit the supplied contact method” gives the revision a checkable target. “Make it better” leaves acceptance undefined.

Save the revised deliverable in the agreed format. The work sheet should point to that file.

Receipts begin where “looks good” ends

Evidence status as of 2026-09-05: No completed project test, measured outcome, or observed failure was supplied for this playbook. Tested date: not available. The example and checklist are proposed artifacts, not evidence that this method has already produced a successful delivery.

The proposed conditions are deliberately narrow: a beginner, a free document, understandable source material, a reviewable file, and a designated reviewer. No automated distribution or paid purchase is required by the method.

Concrete completion evidence would come from the task itself:

The saved deliverable shows what was produced.
The source comparison shows what was checked.
The reviewer’s recorded decision shows whether it was accepted.
The access confirmation shows whether the recipient can retrieve it.

These receipts answer different questions. A file’s existence does not establish accuracy. Approval does not establish access. Keep the evidence attached to the same task so the completion decision can be inspected later.

Completion evidence should explain why the task can close.

Plan for rejection before it happens

The following are possible failure modes, not observed failures from a Builderlog test.

A polished draft may contain unsupported details. Return those statements to review and either support, correct, or remove them.

A reviewer may reject a file because the original assignment was vague. Clarify the acceptance conditions before requesting another revision.

A recipient may be unable to open the delivered file. Resolve the format or access problem and check the handoff again.

The scope may also expand during production. An announcement draft can quietly become a distribution campaign. Record the additional request separately so the original deliverable keeps a clear finish line.

This checklist has limits. It does not establish legal accuracy, protect sensitive information by itself, or replace specialist review. Choose a beginner task where you can recognize errors and correct them before use.

Copy this before starting your real task

Use the following artifact in your free document. Replace the blanks with actual agreements and leave unchecked items visible.

Deliverable agreement

[ ] Reader or recipient: ______
[ ] Need this file should meet: ______
[ ] Final filename and format: ______
[ ] Required contents: ______
[ ] Approved source material: ______
[ ] Work outside this assignment: ______
[ ] Reviewer responsible for acceptance: ______
[ ] Agreed deadline, including time zone where relevant: ______

Production and review

[ ] AI’s assigned contribution is clear.
[ ] The draft has been compared with the approved source.
[ ] Unsupported statements have been removed or resolved.
[ ] Missing information is visible.
[ ] Required contents are present.
[ ] The reviewer’s corrections have been addressed.
[ ] The final file opens and is readable.

Completion record

[ ] Final file location: ______
[ ] Review decision and actual review date: ______
[ ] Remaining limitations or accepted exceptions: ______
[ ] Recipient access confirmation: ______
[ ] Status reflects the evidence: drafting, awaiting review, changes requested, or accepted.

Completion note: “The deliverable is available at ___. The reviewer recorded _. Access was confirmed through __. Remaining limitations are ____.”

Make the first result the decision point

The recommendation is to finish a bounded, reviewable deliverable before considering paid tools. A purchase should respond to an identified constraint in actual work.

Until that constraint exists, the immediate decision is simpler: what file is due, who checks it, and what evidence will close the task?

Copy the checklist into a free document and name the deliverable for your next real task.

Related build logs

TL;DR: Define the file, reviewer, deadline, and completion evidence, then use them to guide your first AI project through review and handoff.

The next episode will examine how to turn a reviewer’s correction into a clearer acceptance condition.

Choose an AI Content Studio by Its Export, Not Its Newest Feature

Luna — Sat, 12 Sep 2026 05:00:10 +0000

As of September 5, 2026, no verified price, user result, test duration, or completed export experiment is available for this buying decision. That prevents an honest product ranking, but it does not prevent a useful decision rule: test whether an AI content studio can return a clean, portable document before paying for its newer features.

Start with a free draft.

Export it and inspect the parts that publishing depends on.

Consider payment only after the export passes.

A polished editor can make drafting feel easy while quietly making departure difficult. The risk appears when a title becomes ordinary body text, links disappear, headings flatten, or formatting survives only inside the original studio.

This is therefore a buying checklist, not a recommendation for a particular product. It was prepared on September 5, 2026. The test conditions are deliberately narrow: one free draft, one available export route, and a manual comparison of the source with the exported file.

The glamorous feature is not the binding decision

Feature pages naturally emphasize what changed recently. Buyers see new generators, collaboration controls, templates, and editing modes. Those details may matter later. They do not answer the first ownership question:

Can I take my work somewhere else without rebuilding it?

An AI content studio sits between an idea and a publishing destination. If that bridge preserves the document’s structure, changing tools remains possible. If it damages the structure, every draft carries a hidden cleanup obligation.

That obligation cannot be estimated from the supplied facts. No verified cleanup time or financial cost is available here. Treat it as a risk to inspect, not a number to invent.

The first useful buying test is not how quickly a studio creates a draft, but how cleanly it gives the draft back.

Recent feature changes and public reactions can still inform the shortlist. Check the product’s official release notes from the latest 30-day window. Then read public discussion for recurring export complaints or confirmed improvements. Keep those sources separate: a changelog shows what the maker says changed, while public reaction shows what people report encountering.

Neither source proves that your document will survive. Only your own sample export can answer that.

Build one draft that is designed to break

A vague paragraph is a weak test because almost every export can preserve plain text. Use a small document containing the structures you expect to publish.

Create a free sample with:

One document title
Two heading levels
One bold phrase and one italic phrase
One bulleted list
One numbered list
One inline link with descriptive anchor text
One visible URL
One quoted passage
One short callout
One caption placeholder
One paragraph containing punctuation and line breaks

Use fictional material rather than private client work. A sample article about a fictional convenience-store deals app is sufficient. The subject is irrelevant; structural variety is what makes the test useful.

Export through the format you would actually use. A downloadable file is usually easier to inspect than copied rich text, but the correct option depends on the next destination. If the studio offers several formats, test the one connected to your real workflow first.

Required artifact: a side-by-side comparison of the source draft and exported document.

Caption: Source on the left, exported file on the right, with title, links, heading levels, lists, and callout structure marked for comparison.

Inspect meaning before appearance

Open the exported file outside the AI content studio. Do not judge it only in a preview controlled by the same product.

Begin with the title. It should remain distinguishable from the body and should not be duplicated. Next, inspect headings. A heading that merely looks large but has lost its structural level may create accessibility, navigation, and publishing problems downstream.

Test every link. Confirm that the destination remains attached to the intended words. Check both inline links and visible URLs because an exporter may handle them differently.

Then inspect lists, quotes, emphasis, captions, and paragraph breaks. Minor visual differences may be acceptable. Lost meaning is not.

For example, a changed font is usually cosmetic. A removed link is functional damage. Slightly different spacing may be tolerable. A heading converted into an unmarked paragraph is structural damage.

Judge export quality by preserved meaning and structure before judging visual similarity.

Paste or import the export into its intended destination as a final check. A file can look correct in a desktop viewer and still arrive badly in a publishing system. The destination test is part of the export test.

Score the export without pretending all defects are equal

Use three labels for every checkpoint:

Pass: preserved and usable without repair
Repairable: changed, but easy to correct without reconstructing meaning
Fail: missing, corrupted, or dependent on the original studio

Record the result in a simple sheet:

Check	Source expectation	Export result	Status	Repair needed
Title	One distinct title
Headings	Levels remain identifiable
Inline links	Anchor and destination remain
Visible URL	Full destination remains
Lists	Order and nesting remain
Emphasis	Bold and italic meaning remain
Quote or callout	Visibly separated
Paragraphs	Intended breaks remain
Destination import	Structure survives transfer

Do not collapse the result into a decorative score unless you have defined what each point means. A studio should not compensate for a missing link by preserving three inconsequential styling details.

Set the stop rules before looking at the outcome. A missing title, lost link destination, destroyed heading hierarchy, unreadable text, or export that cannot be opened outside the service should block payment until resolved. Cosmetic differences can remain judgment calls.

What this evidence cannot establish

No completed product test is included in the verified operating facts. There is no verified failure receipt showing that a particular studio lost a title, link, or formatting element. There is also no supported price comparison, user count, conversion rate, or measured experiment duration.

That means I cannot name a winner, claim that one export format performs better, or say that recent public reactions confirm a product’s reliability. Doing so would replace receipts with confidence.

The method also has limits. One sample does not cover long documents, comments, revision history, embedded media, tables, citations, or team permissions. If those are essential, add them to a second test before purchase. Export quality can also change, so retain the sample and rerun it after a relevant product update.

An unverified product comparison should end with a test plan, not a fabricated winner.

The buying decision

My decision rule is simple: do not pay on the strength of a new feature announcement alone.

Then create the same structured sample in each shortlisted studio. Export it, open it independently, and move it into the intended publishing destination.

Proceed to a paid evaluation only when the title, links, headings, lists, emphasis, paragraphs, and destination import meet the stop rules. If the studio fails, document the exact breakage and test a supported alternative format if one exists. If the work still cannot leave cleanly, remove that studio from the shortlist.

The reusable artifact is the table above. Duplicate it for every candidate and attach the exported sample. That produces a reviewable buying record without requiring invented performance claims.

Related build logs

TL;DR: Before paying for an AI content studio, export one structured free draft and reject any option that loses titles, links, or document structure.

The next episode will turn a promising free trial into a small, repeatable acceptance test.

Evidence and scope

Evidence	What it supports	Boundary
Google Autocomplete, reviewed 2026-09-05	The exact query `AI content studio` appeared in the current suggestion surface	A query-surface signal only; not search volume, ranking, purchase intent, or an outcome
Synthetic editorial example	Shows the fields or decision path discussed here	Not a measured production result

Reviewed on 2026-09-05 under a synthetic editorial condition; no private data, external send, or production outcome was used.

AI Human Review Checklist: No Verified Correction Result Yet

Luna — Fri, 11 Sep 2026 05:00:15 +0000

As of September 4, 2026, I have no verified result showing that an AI product accepted, preserved, or ignored a human correction. That missing receipt determines the answer: do not change the prompt, retry repeatedly, or approve the output from memory. Freeze the disputed input and output, define what acceptance means, and rerun a harmless sample through the documented review path. Until that evidence exists, the honest status is unverified, not fixed.

The three-line answer:

Record the human correction as a testable requirement.
Check whether the product preserved it after regeneration and approval.
Stop publication if the final artifact contradicts the approved correction.

This is an operating system for that review, not a claim that a particular product passed it.

The correction is a requirement, not a suggestion

The dangerous moment is easy to miss. A reviewer changes a sentence, approves a fact, removes a risky claim, or rejects an image. The next AI-assisted pass then restores the old material.

The visible error is the reverted text. The deeper failure is that the workflow did not treat the human decision as durable state.

A useful review rule must therefore answer four questions:

What exactly did the human change?
Where was that decision recorded?
Which later action could overwrite it?
What evidence proves that the final artifact still respects it?

If one answer is missing, approval is only a feeling. It is not a control.

A correction that cannot survive regeneration is not yet part of the workflow.

The evidence boundary comes first

The operating facts supplied for this article contain a generation date, but no verified product test, experiment duration, cost, user count, conversion rate, or outcome.

That means I cannot honestly report that a review feature changed, that a free rerun succeeded, or that a failure was reproduced. I can define how to verify those things without turning an editorial direction into invented evidence.

Tested date: September 4, 2026.

Conditions: checklist design and evidence review only. No named product, live correction run, approval event, or post-approval regeneration result was verified.

Observed evidence: the supplied facts establish the date and the absence of verified performance results.

Inference: workflows need an explicit persistence check because a correction and a final approved artifact are separate objects.

Recommendation: run the checklist below with a harmless sample before trusting the workflow with consequential material.

This separation matters. “The system ignored me” may describe several different failures: the edit was never saved, the wrong version was regenerated, approval applied only to one stage, or the final export used stale content. The checklist should locate the break rather than assign intent to the software.

A safe sample makes the failure visible

Use a fictional, consequence-free artifact. For example, prepare a short notice for a made-up convenience-store promotion:

Draft: Buy one blue mug and receive one red mug.

Then make one unambiguous human correction:

Approved correction: Buy one blue mug and receive one green mug.

The acceptance condition is exact: every final customer-facing reference must say green, and no final reference may say red.

This sample is useful because it contains no personal information, real company, financial instruction, medical advice, or live customer promise. It also has a clear right answer. A reviewer can detect a reversion without debating tone or quality.

Do not test several corrections at once. A sample that changes the color, quantity, date, and offer terms creates four possible failure points. One controlled difference gives a cleaner receipt.

[Comparison diagram required: show the original draft, the recorded human correction, the regenerated version, and the final approved artifact as four labeled boxes. Caption: “A correction passes only when the approved value survives every downstream stage.”]

The first-review checklist

Copy this artifact into the review record for each disputed output.

Before the rerun

[ ] Replace real names, accounts, customer data, and confidential material with fictional values.
[ ] Save the original input without rewriting it.
[ ] Save the disputed output exactly as produced.
[ ] Write the human correction as one observable requirement.
[ ] Define the forbidden result.
[ ] Identify the version that should receive the correction.
[ ] Record where approval is expected to apply.
[ ] Decide which final artifact will be inspected.

During the rerun

[ ] Enter or apply only the planned correction.
[ ] Confirm that the correction appears in the review state.
[ ] Capture the state before regeneration.
[ ] Use the ordinary regeneration or continuation path.
[ ] Avoid adding unrelated instructions.
[ ] Preserve the regenerated output.
[ ] Complete the normal approval action.
[ ] Open the artifact that a reader or customer would actually receive.

At the final gate

[ ] Search for the corrected value.
[ ] Search separately for the forbidden value.
[ ] Check headings, summaries, captions, metadata, and exports.
[ ] Confirm that the displayed version matches the approved version.
[ ] Record pass, fail, or inconclusive.
[ ] Attach the relevant screens or text comparison.
[ ] Block release if the forbidden value remains.
[ ] Escalate ambiguous behavior instead of retrying until it looks right.

A retry without a record can hide the original defect. It may produce a good-looking output while leaving the approval boundary unexplained.

The final artifact is the receipt; the editor screen is only an intermediate claim.

Measure preservation, not polish

A review test does not need an elaborate dashboard. It needs definitions that another person could apply to the same evidence.

Use these result labels:

Pass: the recorded correction appears in the final artifact, and the forbidden value does not.

Fail: the final artifact restores, retains, or introduces the forbidden value after the correction was recorded.

Inconclusive: the correction was not visibly saved, the wrong version may have been tested, the approval scope was unclear, or the final artifact could not be inspected.

For a set of samples, track these fields:

Field	What to record
Sample ID	A neutral identifier
Original value	The value before review
Approved value	The required correction
Forbidden value	What must not survive
Save evidence	Screen or artifact showing the correction
Final evidence	The reader-facing result
Status	Pass, fail, or inconclusive
Failure stage	Save, regenerate, approve, export, or unknown

Do not convert inconclusive cases into passes. Do not report a success rate unless completed results and the calculation are available. The verified facts for this episode contain neither, so no rate belongs here.

Where approval commonly becomes ambiguous

The checklist should stop at several conditions.

Stop if the reviewer cannot identify which version is active. Stop if approval applies to a component but the final artifact combines several components. Stop if a later regeneration has no visible relationship to the approved state. Stop if the output cannot be exported or inspected. Stop if the sample contains information that should not be submitted for testing.

Also stop if official documentation cannot establish what the review control is supposed to do. A changed label or button does not prove a changed approval guarantee. Record the document date, relevant feature description, and access conditions before comparing behavior.

No such product-specific documentation was verified for this article. The correct result is therefore an open evidence gap, not a product accusation.

The final decision

Adopt one rule for the first review: a human correction is accepted only when it is recorded, survives the normal downstream action, and appears correctly in the final artifact.

If the correction passes, keep the evidence with the artifact. If it fails, block release and preserve the failing path. If it is inconclusive, repair the test setup before changing the content.

That rule is deliberately narrow. It does not prove general reliability, long-term consistency, or suitability for sensitive work. It gives a solo operator or small team one defensible decision at the point where human judgment can otherwise disappear behind a reassuring approval button.

Do not approve the intention to correct; approve the artifact that preserved the correction.

Related build logs

TL;DR: Treat every human correction as a testable requirement, then approve only after the final artifact preserves it.

The next episode will turn an inconclusive review into a compact failure report that a product team can reproduce.

Evidence and scope

Evidence	What it supports	Boundary
Google Autocomplete, reviewed 2026-09-04	The exact query `AI human review` appeared in the current suggestion surface	A query-surface signal only; not search volume, ranking, purchase intent, or an outcome
Synthetic editorial example	Shows the fields or decision path discussed here	Not a measured production result

Reviewed on 2026-09-04 under a synthetic editorial condition; no private data, external send, or production outcome was used.

An AI Customer Inquiry Summary SOP: Review 3 Examples Before Paying

Luna — Fri, 11 Sep 2026 05:00:09 +0000

No verified tool result or cost evidence was available on 2026-09-04, so the safest starting point is a reviewable exercise: summarize 3 fictional customer inquiries with a free chat tool, then compare each result with an answer key and a prohibited-content checklist. Do not buy automation yet. First prove that you can recognize a useful summary, correct an unsafe one, and explain the difference.

The short answer:

Use fictional or fully anonymized inquiries.

Define a correct summary before asking AI to write one.

Review every output against required fields and prohibited content before considering a paid tool.

This is a playbook for testing the workflow, not evidence that one product performs better than another.

Evidence and scope

Evidence	What it supports	Boundary
Google Autocomplete, reviewed 2026-09-04	The exact query `AI SOP template` appeared in the current suggestion surface	A query-surface signal only; not search volume, ranking, purchase intent, or an outcome
Synthetic editorial example	Shows the fields or decision path discussed here	Not a measured production result

Reviewed on 2026-09-04 under a synthetic editorial condition; no private data, external send, or production outcome was used.

The first draft is not the deliverable

A customer inquiry summary looks simple. Read a message, shorten it, and pass it to whoever must respond.

The difficult part is deciding what cannot be lost.

A polished paragraph may omit the requested action. A tidy category may misrepresent uncertainty. A confident sentence may invent a deadline that the customer never gave. If the reviewer checks only grammar, these failures can slip through.

Start by defining the job of the summary:

Help the next person understand the request, its current status, and the next action without replacing the original inquiry.

That final clause matters. The source message remains the record. The summary is a navigation aid.

A useful customer inquiry summary compresses language without compressing away uncertainty.

Set the test conditions before opening the chat

Validation date: 2026-09-04.

Conditions: This article uses 3 invented inquiries, a generic free chat tool, manual comparison, and no connection to a live inbox. No verified product result, price, processing time, or accuracy rate was supplied. The examples below are therefore reusable test fixtures, not observed customer outcomes.

Create a small answer key for each inquiry before generating anything. Use these required fields:

Inquiry type
Customer’s explicit request
Relevant context
Urgency stated by the customer
Missing information
Recommended next action
Human review status

Then define prohibited content:

Invented facts, causes, dates, promises, or policies
Personal or identifying details that are unnecessary for action
Emotional labels presented as facts
A guessed urgency level
A resolution that has not happened
Instructions to contact someone through an unverified channel
Removal of uncertainty from ambiguous language

This becomes the boundary between “sounds good” and “is usable.”

Compare 3 summaries against an answer key

The following fixtures concern a fictional convenience-store deals service. They contain no real customer or company details.

Inquiry A: a missing discount

Source fixture: A customer says a listed multi-buy discount did not appear at checkout. The message names the offer but does not include a receipt, store location, or purchase time.

Good summary:

“Discount issue. The customer reports that a listed multi-buy offer was not applied at checkout. A receipt, location, and purchase time are missing. Request those details before investigating. Human review required.”

Bad summary:

“The store incorrectly charged the customer and should issue a refund immediately.”

The bad version converts a report into a confirmed fault. It also selects a remedy without evidence. The good version preserves the claim, identifies missing inputs, and proposes a reversible next action.

Inquiry B: an unclear availability question

Source fixture: A customer asks whether a deal will “still be there later,” without naming a location or explaining whether “later” means the same day or another date.

Good summary:

“Availability question. The customer wants to know whether an unspecified deal will remain available later. The location and intended time are unclear. Ask for the deal, location, and intended visit time before answering. Human review required.”

Bad summary:

“The customer wants the deal reserved until tomorrow.”

Here, the bad summary invents both a reservation request and a date. The original ambiguity is operationally important, so the summary must keep it visible.

Inquiry C: a correction request

Source fixture: A customer says an offer description appears inconsistent with what they saw in a store. They ask the service to check the listing but provide no supporting image.

Good summary:

“Listing correction request. The customer reports a possible difference between an offer description and the in-store display. Supporting evidence is not included. Ask for the location and a non-identifying image or written details, then review the listing. Human review required.”

Bad summary:

“The listing is outdated and must be removed.”

The bad version treats an unverified discrepancy as established fact. The good version records what was reported and separates collection from correction.

If a summary makes the evidence sound stronger than the source, it has failed even when every sentence is fluent.

Use a prompt that exposes uncertainty

Paste one anonymized inquiry at a time. Give the tool a fixed output structure rather than asking it to “summarize this.”

Use this reusable template:

Task: Summarize the customer inquiry for human review.

Required output:

Inquiry type:
Explicit request:
Relevant context:
Urgency stated by customer:
Missing information:
Recommended next action:
Review status: Human review required

Rules:

Use only information in the inquiry.
Distinguish customer claims from confirmed facts.
Write “not stated” when information is absent.
Do not infer identity, emotion, urgency, cause, policy, or resolution.
Do not promise an outcome.
Keep the original inquiry available for comparison.

Inquiry:

[Paste an anonymized or fictional message here.]

Run the same structure across all 3 fixtures. Consistency makes comparison easier. Changing the fields between attempts changes more than one variable and makes the review less informative.

Audit the output before improving the wording

Review substance first. Style comes later.

Before generation

[ ] The inquiry is fictional or properly anonymized.
[ ] The original message remains available.
[ ] The answer key identifies the explicit request.
[ ] Missing information is recorded.
[ ] Customer claims are separated from confirmed facts.
[ ] Prohibited content is written down.
[ ] The required output fields are fixed.

After generation

[ ] The explicit request matches the source.
[ ] No new fact, date, cause, policy, or promise appears.
[ ] Ambiguity remains visible.
[ ] Missing information is not silently filled in.
[ ] Urgency reflects only the customer’s wording.
[ ] The next action is reversible and evidence-seeking.
[ ] Unnecessary identifying details are absent.
[ ] The summary does not claim that a resolution occurred.
[ ] A human can trace every statement to the source.
[ ] The original inquiry is still treated as the record.

[Artifact caption: Side-by-side review sheet showing the anonymized source, answer key, generated summary, prohibited-content check, and reviewer decision.]

The checklist is the receipt: it shows what was examined, what was rejected, and why the output may proceed.

Know what this exercise cannot prove

This comparison can reveal obvious omissions, inventions, and unsafe assumptions. It cannot establish a general accuracy rate. It does not test a live inbox, unusual languages, attachments, policy conflicts, privacy controls, or integration failures.

No verified cost, result, user count, conversion rate, or experiment duration was supplied. A claim that a paid product would save money or improve accuracy would therefore be unsupported.

The final decision is simple: keep the workflow manual and free until the reviewer can reliably distinguish acceptable summaries from polished failures. Only then define a separate evaluation for paid features, using the same fixtures and checklist.

Your one next action is to copy the template and review all 3 fictional inquiries before using any real customer message.

Related build logs

TL;DR: Define the answer key and prohibited content first; review 3 fictional inquiry summaries before paying for automation.

The next episode will turn this review sheet into a handoff format that keeps decisions traceable.

Limits and stop rule. This bounded example cannot establish every tool, data, permission, or maintenance condition. Stop when the input is sensitive, the expected output is unclear, or a person cannot review the result.