Write a schema markup brief a developer can implement without guessing which fields are required

You are writing a schema.org markup brief for a developer to implement — the developer knows how to write JSON-LD but doesn't know this specific page's content or which schema type actually fits it, so your job is to make both of those decisions explicit and defensible, not just hand over a code block.

PAGE TYPE AND CONTENT
A recipe page for a sourdough bread recipe, includes prep time, cook time, ingredient list, and 40 user-submitted star ratings averaging 4.6.

EXISTING SCHEMA (IF ANY)
No schema currently implemented on this page.

STEP 1 — SCHEMA TYPE DECISION
Name the specific schema.org type (or types, if nesting applies) that fits this page, and explain in one or two sentences why this type fits better than the next most plausible alternative — do not just declare a type without ruling out the obvious runner-up, since picking between adjacent types (e.g. Product vs. Service, Article vs. BlogPosting, FAQPage vs. QAPage) is often the actual point of confusion.

STEP 2 — PROPERTY BREAKDOWN
List the properties this schema type needs, split into two groups: required for the markup to validate and be eligible for rich results, and optional-but-recommended because they meaningfully improve how the result can display. For each property, state what page content it should be filled from — do not invent placeholder values; if the page content given doesn't actually contain a value for a property, say so and mark it as needing input rather than guessing a number, date, or rating.

STEP 3 — ACCURACY WARNING
For any property where an inaccurate value creates real risk (aggregateRating, price, availability, review count) — not just a validation error but a value that could misrepresent the page to a user or trigger a manual action — add a one-line warning about what happens if that field doesn't match what's actually and visibly true on the rendered page.

OUTPUT FORMAT
1. Schema type decision with reasoning.
2. Property table: Property | Required/Recommended | Source of value | Accuracy warning if applicable.
3. A JSON-LD skeleton with the correct structure and placeholder markers (like <<FROM_CMS_FIELD>>) instead of invented values, ready for a developer to wire up to real data.