Two AI applications can accept the same photograph and produce outputs that look equally convincing while doing entirely different work. One describes visible damage in an inspection image; the other creates a marketing illustration of a repaired product. The first is constrained by observed evidence. The second is allowed to invent details within a creative brief. Confusing these goals makes it easy to choose the wrong model, collect the wrong evaluation data, or present generated imagery as if it were factual proof.
An image app describes damage visible in a customer’s photograph, while a second model generates a fictional room illustration. Both use visual input, but one must preserve evidence and the other follows a creative brief. Microsoft AI-901 covers multimodal visual prompts, image generation and lightweight vision clients. The developer must check supported deployment modalities, evaluate observable facts separately from creative quality and disclose when an output is generated imagery rather than factual documentation.
Start with the question the image must answer
A customer-uploaded photograph may be used to identify a furniture type or describe observable damage. The application should ask what can reasonably be concluded from the pixels: is a chair visible, what color is it, and which regions appear damaged? A marketing prompt, by contrast, might ask a generator to place the chair in a bright living room. In the second case, the resulting background has no factual relationship to the customer’s property. Product managers must label those modes clearly.
Write separate output contracts. A visual-understanding result should include the claim, supporting image or region, and uncertainty where the observation is ambiguous. A creative result should include the requested style, protected product attributes and review criteria. Computer vision in Foundry distinguishes image understanding from creative image generation by what must be preserved, not merely by the media format.
Choose a model that accepts the required modality
Some models accept text only; supported multimodal models can process images alongside text; image-generation models create new visual assets, sometimes with editing features that depend on the exact service and model. Do not assume every model marketed as multimodal can perform all three actions. Review the current model card and the deployed region’s supported features, input limits and content policies before designing the interface around a capability it may not have.
A model that interprets a photograph can be asked, ‘Describe only what is visibly present in this picture. Choosing the right AI model requires validating input and output capabilities, deployment constraints and measured performance before choosing a provider.
Write prompts that control unsupported inferences
An image question must avoid encouraging the model to invent invisible information. For a photograph of a scratched table, it is reasonable to describe the visible scratch and its approximate position. It is not reasonable to assert when it occurred, what chemical caused it, or whether the product warranty applies. Those facts require separate evidence. A useful prompt tells the model to distinguish observable facts from speculation and to ask for another angle when the image lacks a decisive view.
Test a few deliberately hard cases: a partially occluded object, a low-light image, a reflective surface and a picture containing text. The model may confuse visible labels or interpret shadows as defects. Measure those failures instead of accepting any articulate response. When the next step is a return authorization, the application must still consult approved account and warranty data. A vision model cannot independently grant customer permissions.
Treat generated image instructions as a creative brief
A generative image prompt can specify the subject, composition, lighting, camera perspective and protected constraints. ‘A chair in a room’ gives the system too much freedom for a real catalog. ‘Show the supplied blue chair without changing its upholstery pattern; use a neutral interior and leave a clear title area at upper left’ provides criteria that a reviewer can examine. Some deployments support image references or edits; others require fresh generation. Verify which operation is available before promising preservation of a supplied product.
Keep the original asset and record which output version was approved. A later revision that changes the background could also alter a logo, leg count or color. Compare those attributes against the source and reject an output that misrepresents the product. The point is not eliminating creative variation. It is identifying which variations are permitted and which turn marketing artwork into inaccurate product information.
Build a lightweight upload-and-review experience
A simple client should validate file size and supported format, let the user choose between describing and generating, and submit the request to a correctly configured model deployment. Store only the information necessary for the task, and avoid including private customer photographs in unrestricted logs. Show clear loading and error states; a large image may take longer to process than a short text prompt. If a service refuses a request or cannot inspect the content, surface that outcome instead of substituting an invented description.
For visual understanding, display the result alongside the submitted photograph so a reviewer can check what was actually visible; do not present an interpretation as a verified inspection decision. In generation mode, show the result beside the creative brief and retain the approved asset so a rejected variant cannot overwrite it. Before writing the upload client, confirm that the specific Foundry model deployment accepts the intended image input or generation operation, including its available region, payload limits and supported formats. An SDK method name cannot make an unsupported modality work.
Keep OCR and structured extraction in their own lane
A picture may contain an invoice, product label or technical diagram with text that needs to become a reliable field. Visual question answering can discuss the image, but it is not a substitute for a properly validated extraction workflow when the application needs an exact amount or identifier. Image generation is less suitable still, because its purpose may be to create details that never existed. Ask whether the task is to interpret, extract, classify or generate before selecting the service.
If the business requires line items from an invoice or a serial number from a form, Content Understanding with field schemas may provide the more relevant pattern. A schema can tell downstream software which field was extracted, its expected type and available source context. That gives application code something specific to validate instead of trusting a fluent free-form description of a photograph.
Test privacy, inclusion and visual fidelity
Photographs can reveal faces, addresses, device screens and private surroundings. Decide what the service needs to see and how long the input and output should be retained. For an employee equipment-inspection application, crop irrelevant personal surroundings when possible. Do not assume that a visually generated result is safe to publish just because it passed a model’s internal filters. Rights to an input asset, brand fidelity and harmful content may require additional review.
Evaluation should include differently lit and composed images, diverse subjects where relevant, small text, unusual camera angles and people with varied accessibility needs. Look at errors by input class rather than only average quality. The same application may perform well on well-lit catalog photographs and poorly on images submitted from inexpensive phones. Responsible AI scenario testing helps translate fairness, reliability and privacy principles into cases that a small development team can actually execute.
Use a reviewer rubric for both visual tasks
A small visual-understanding evaluation sheet can ask whether the model correctly identified the object, described only visible damage, preserved text labels and expressed uncertainty for hidden regions. Use photographs with unusual lighting and several camera angles. Mark a description incorrect if it confidently infers a manufacturer or cause from information not visible in the image. The rubric should refer to evidence a reviewer can inspect, not to how persuasive the model’s prose sounds.
A creative-generation rubric asks different questions: does the product’s shape match the approved reference, are requested composition and background conditions met, and did any logo or important color change unintentionally? Keep unsuccessful samples for regression tests rather than selecting only the most attractive outputs. A later model version might improve lighting while losing product fidelity, which may be an unacceptable tradeoff for a catalog. Separating both review rubrics lets a team value genuine image understanding and imaginative design without confusing one for the other.
Distinguish a compelling picture from a trustworthy result
For image interpretation, success means the output stays faithful to visible evidence and identifies uncertainty where appropriate. For image generation, success means the result meets the stated creative constraints and passes policy and asset reviews. Those criteria cannot be replaced by a single aesthetic score. A plausible picture of a damaged appliance is not evidence that the customer’s original photograph showed that damage.
The AI-901 vision objective becomes easier when applications are classified by what they are allowed to invent. A careful lightweight client selects the correct deployed capability, validates input, preserves source evidence or an asset brief, and offers a review process matched to the consequences of an error. The point is not that one model can do everything with images; it is knowing why a particular visual workload is being built and how its result will be trusted.