docs: clarify evaluation and resolution details

[Rul1an]

What changed

Clarifies the relationship between evaluation details and resolution details in specification/types.md.

The update:

• uses “detailed flag evaluation functions” for the application-facing API surface
• describes evaluation details as the application-facing result returned from detailed flag evaluation
• describes resolution details as the provider-to-SDK return shape used to build evaluation details

Why

The two structures share many fields, which can make it unclear why both exist. This adds a small docs clarification without changing any requirements or API behavior.

Fixes #168.

Validation

Ran locally:

npm ci
python3 ./tools/specification_parser/specification_parser.py
tmpbin=$(mktemp -d) && ln -s "$(command -v python3)" "$tmpbin/python" && PATH="$tmpbin:$PATH" make parse
make markdown-toc
./node_modules/.bin/markdownlint specification/types.md
npx -p node@24 -c './node_modules/.bin/markdown-link-check -c .markdown-link-check-config.json specification/types.md'
tmpbin=$(mktemp -d) && ln -s "$(command -v python3)" "$tmpbin/python" && PATH="$tmpbin:$PATH" npx -p node@24 -c 'make lint'
git diff --check

[gemini-code-assist]

Code Review

This pull request updates the specification/types.md file to clarify the roles of evaluation details and resolution details, ensuring a clear distinction between application-facing results and provider-to-SDK data structures. It also corrects terminology regarding flag evaluation functions. Feedback was provided to improve terminological precision, specifically to avoid ambiguity with the flag metadata field and to maintain consistency with existing specification terms like 'resolution details' and 'error information'.

[Copilot]

Pull request overview

Clarifies the distinction between evaluation details (application-facing output of detailed flag evaluation) and resolution details (provider-to-SDK result used to build evaluation details) in the OpenFeature specification docs.

Changes:

• Updates terminology to refer to “detailed flag evaluation functions” for the application-facing API.
• Adds a NOTE explaining evaluation details as the application-facing result and how it relates to resolution details.
• Expands the NOTE for resolution details to describe the provider-to-SDK contract and how SDKs construct evaluation details.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Rul1an]

Small downstream context, no action needed here: this clarification around application-facing evaluation details vs provider resolution details is also the seam I used in an Assay-side release as a bounded runtime-decision receipt path.

It stays outside OpenFeature and is framed as downstream use of the existing detailed evaluation surface, not as an integration, support, or partnership claim.

Assay release: https://github.com/Rul1an/assay/releases/tag/v3.8.0
Latest note: https://github.com/Rul1an/assay/blob/main/docs/notes/EVIDENCE-RECEIPTS-FOR-AI-OUTCOMES-RUNTIME-DECISIONS-MODEL-INVENTORY.md
Recipe: https://github.com/Rul1an/Assay-Harness/blob/v0.3.1/docs/OPENFEATURE_DECISION_RECEIPT_PIPELINE.md