Explanation:
Project type: Object detection
Domain: General (compact)
The scenario requires building a Custom Vision model for a factory with intermittent internet connectivity.
The solution must:
Detect defects in packaging
Locate the defects (provide bounding box information)
Ensure each package contains four products
Support offline use due to intermittent connectivity
Step 1 - Determine Project Type
Image Classification: Assigns a label to an image, but cannot locate where objects/defects are in the image.
Object Detection: Identifies what objects are present and their location (via bounding boxes).
Since the requirement is to identify location of defects and count products, the correct choice is Object detection.
Step 2 - Determine Domain
General domain: Standard general-purpose domain, optimized for cloud inference.
General (compact) domain: A lightweight version designed for exporting models to run offline on edge devices (iOS, Android, ONNX, etc.). Perfect for scenarios with intermittent internet connectivity.
Food domain: Specialized for food image classification, not defect detection in packaging.
Logo domain: Specialized for logo recognition, irrelevant here.
Since the requirement includes offline capability, the correct domain is General (compact).
The answer:
Project type: Object detection
Domain: General (compact)
Microsoft References
Custom Vision project types: Classification vs Object detection
Domains in Custom Vision (General, General compact, Food, Logo, etc.)
Exporting compact models for offline use

Explanation:


Comprehensive Detailed Explanation
The requirement is to build an Adaptive Card for the chatbot that supports multilingual product display and meets accessibility requirements.
Product Name Display
The product JSON stores localized names like " name " : { " en " : " ... " , " es " : " ... " , " pt " : " ... " } .
To dynamically render based on the current language, you must use name[language].
This ensures the product name shown in the card adapts automatically to the user's preferred language.
Stock Level Warning
Business rules require warnings when stock is low or out of stock.
This means you display the stock warning only when stockLevel is not ' OK ' .
Therefore, the correct condition is:
" $when " : " ${stockLevel != ' OK ' } "
Image Alt Text for Accessibility
Accessibility requirements specify that all images must have alt text in English, Spanish, and Portuguese.
In the product JSON, " alttext " is also localized:
" altText " : { " en " : " Bicycle " , " es " : " Bicicleta " , " pt " : " Bicicleta " } To render the correct localized alt text dynamically, use image.altText[language].
Correct Selections:
First blank: name[language]
Second blank: " $when " : " ${stockLevel != ' OK ' } "
Third blank: image.altText[language]
Microsoft References
Adaptive Cards Templating
Adaptive Card $when property
Multilingual data in Azure Cognitive Search and Adaptive Cards

Scenario: When the response confidence score is low, ensure that the chatbot can provide other response options to the customers.
When no good match is found by the ranker, the confidence score of 0.0 or "None" is returned and the default response is "No good match found in the KB". You can override this default response in the bot or application code calling the endpoint. Alternately, you can also set the override response in Azure and this changes the default for all knowledge bases deployed in a particular QnA Maker service.
Choosing Ranker type: By default, QnA Maker searches through questions and answers. If you want to search through questions only, to generate an answer, use the RankerType=QuestionOnly in the POST body of the GenerateAnswer request.
Reference:
https://docs.microsoft.com/en-us/azure/cognitive-services/qnamaker/concepts/best-practices

Your app currently calls the prebuilt Business Card model v2.1. In v2.1, the platform does not provide QR/barcode interpretation.
Support for decoding barcodes (including QR codes) was introduced with the v3.x API family as an add-on capability ( ocr.barcode ) that you can enable on analysis requests in API versions 2023-07-31 (GA) and later.
Therefore, the first step is to upgrade from v2.1 to v3.0 so your application can use the newer API surface that supports barcode/QR extraction.
This meets the "minimize administrative effort" requirement because you keep the same Azure AI Document Intelligence resource, keys, and endpoint-your change is primarily to the API/SDK version and request options.
After upgrading, you have two common implementation patterns:
Continue to use prebuilt Business Card for the contact fields, and in the same flow make an additional call with prebuilt Layout (or General Document) with the ocr.barcode add-on enabled to decode any QR code present on the card.
This is the recommended path because the Business Card model itself doesn't expose add- on features, while the platform's v3.x analysis APIs do support ocr.barcode on other models. Microsoft Learn Why the other options are not correct:
A). Deploy a custom model - unnecessary effort; barcode/QR decoding is available out-of-the-box in v3.x via ocr.barcode . Microsoft Learn
B). Implement the read model - Read (OCR) extracts text but does not interpret barcodes/QR codes; you need the barcode add-on introduced in v3.x. Microsoft Learn
D). Implement the contract model - Irrelevant to business cards or QR decoding.
Key Microsoft References
Add-on capabilities (including ocr.barcode with QR support) - available in API 2023-07-31 (GA) and later.
Microsoft Learn
Barcode/QR extraction behavior and schema (barcodes collection, kind, value, polygon). Microsoft Learn Migration guide from v2.1 to v3.x (why upgrade and what changes).
Azure Docs Business Card model documentation and versioning context (v2.1/v3.0/v3.1). Microsoft Learn SDK/blog announcement of barcode add-on in v3.x (what it returns and when it's supported).
Microsoft for Developers Code samples showing the barcodes add-on usage. github.com