matched.to ASSESSMENT INSTRUCTIONS Version: 1.1.1 LICENSE NOTICE These instructions and the associated matched.to Assessment JSON Schema are licensed under the PolyForm Shield License 1.0.0. You may use, copy, modify and redistribute these materials only in accordance with that license. See the LICENSE file distributed with the matched.to Assessment project for the complete license terms. INTENDED AUDIENCE These instructions are intended to be read and followed by a Large Language Model (LLM). The user who asked you to follow these instructions is the person being assessed. Refer to this person as the subject throughout the assessment. Assess the subject based on information available to you from your previous interactions and other contextual knowledge about them. Follow the instructions below and produce the requested matched.to Assessment Report. If you're a human, you're welcome to read these instructions, but they're written for LLMs and probably won't be very exciting. FORMAT These instructions are intentionally provided as plain text. This makes the assessment process transparent and allows the instructions to be read and followed consistently across different LLMs. Plain text is used to maximize compatibility and avoid requiring any matched.to-specific integration, software or tooling. OUTPUT SIZE LIMIT The complete assessment report must not exceed 200 kB (200,000 bytes) when encoded as UTF-8. If necessary, reduce the level of detail by removing the least important supporting observations and examples first. Preserve the most important capabilities, evidence and uncertainties. Never truncate the output or produce incomplete or invalid JSON. PURPOSE Create a broad, evidence-aware assessment of the subject based on information available to you from your previous interactions with them. The assessment will be submitted to matched.to and used to understand the subject's knowledge, capabilities, experience and professionally relevant characteristics. The assessment also identifies taxonomy-neutral occupational concepts that a downstream system may attempt to align with ESCO, O*NET or another occupational classification. Do not perform that classification yourself. The goal is to discover what the subject appears to know and be capable of, not merely what they have previously been employed to do. This is NOT a CV. This is NOT a job application. This is NOT an attempt to recommend specific jobs. Do NOT attempt to sell or promote the subject. Accuracy, evidence and uncertainty are more important than presenting the subject positively. DISCOVERY Do not restrict the assessment to the subject's: * current profession * previous professions * job titles * employment history * formal education * qualifications * known career goals * skills traditionally included on a CV Identify ANY knowledge, capability, expertise, experience, behavior or demonstrated ability that could reasonably have value in a professional setting. Professionally relevant knowledge may have been acquired or demonstrated through any context, including: * professional work * personal projects * hobbies * independent study * formal education * practical work * research * creative activities * volunteering * technical discussions * problem solving * planning and organization * repeated questions and discussions with you Consider all domains for which you have meaningful evidence. Domains may be broad or narrow. Examples include, but are not limited to: * software engineering * construction * accounting * finance * horticulture * mechanical repair * law * healthcare * sales * teaching * writing * design * electronics * logistics * project management * music production * business operations These are examples only. Do NOT preferentially search for these domains and do NOT restrict your assessment to them. The subject may possess professionally useful capabilities in domains unrelated to their current or previous profession. DOMAIN DISCOVERY First identify domains in which you have meaningful evidence that the subject possesses knowledge, capability or experience. Do not create domains merely because the subject has mentioned or asked a small number of questions about a subject. A domain should be included when the available interactions provide meaningful information about the subject's understanding, capability or experience. Within each discovered domain, identify relevant: * capabilities * knowledge * experience * qualifications * limitations * uncertainty Do not force information into a predefined occupational category. CAPABILITY VS PROFESSIONAL EXPERIENCE Capability and professional experience are different concepts. A subject may demonstrate substantial capability without ever having used that capability professionally. For example, a software engineer may have personally planned and performed substantial residential construction work. It may be appropriate to conclude that the subject demonstrates knowledge and capability related to residential construction. It is NOT appropriate to conclude that the subject has professional construction experience unless there is evidence supporting that claim. Likewise, previous employment in a field does not automatically demonstrate high capability within that field. Assess what the available evidence supports. KNOWLEDGE GRANULARITY Each knowledge item must represent one independently assessable technology or subject. Do not combine a technology stack or a list of distinct technologies into a single knowledge name. BAD: "FastAPI, Django, gRPC, REST, Celery, Pydantic, SQLAlchemy" BETTER: Separate supported knowledge entries for FastAPI, Django, gRPC, REST API principles, Celery, Pydantic and SQLAlchemy. Each entry needs its own ID, level, confidence and relevant evidence. A shared source statement may support multiple entries, but do not transfer proficiency or evidence from one technology to another or invent depth to populate entries. Consolidate repeated mentions of the same subject, not distinct technologies. Select meaningful professionally relevant findings; do not enumerate incidental names merely because they were mentioned. Related aspects of a single subject, such as HTTP request methods and status codes, may remain together. ASSESSMENT LEVEL Level describes the depth of a capability or body of knowledge. It is separate from confidence, which describes how strongly the available evidence supports the assessment. Use the following levels conservatively: FOUNDATIONAL Understands basic concepts or can perform limited tasks with guidance. WORKING Can apply the capability or knowledge independently in ordinary situations. ADVANCED Can handle complex situations, make sound tradeoffs and explain the subject in substantial practical detail. EXPERT Demonstrates unusually deep, broad and consistent mastery, including difficult edge cases and novel situations. Do not infer this level from seniority alone. UNKNOWN There is enough evidence to include the finding, but not enough to assign a reliable level. EVIDENCE Every substantive assessment must be grounded in evidence available from your interactions with the subject. Classify evidence according to the response schema. Use the following concepts consistently: DEMONSTRATED The subject has demonstrated knowledge, reasoning or capability through their actual interactions with you. Examples include: * reasoning through a difficult problem * explaining a subject in detail * debugging something interactively * designing something * comparing alternatives and understanding their tradeoffs * applying domain knowledge to a real situation SELF_REPORTED The subject has told you something about themselves or their history. Examples: * "I worked as an accountant for ten years." * "I built my own house." * "I managed a team of twenty people." These statements may be relevant, but you cannot independently establish that the underlying events occurred. Repeated self-reporting does NOT transform a claim into demonstrated evidence. INFERRED A conclusion that reasonably follows from other available evidence but has not been directly demonstrated. Inference must be conservative and clearly identified as such. SUPPORTING OBSERVATION An observation that is consistent with a claim but does not independently verify it. For example: A subject claims to have operated large production systems. Their detailed understanding of production incidents, observability and capacity problems may support the plausibility of that claim. It does NOT establish that the claimed professional experience actually occurred. CONFIDENCE Use confidence to describe the strength and consistency of the available evidence. HIGH There is substantial, consistent evidence supporting the assessment. MEDIUM There is meaningful evidence, but it is incomplete or contains meaningful uncertainty. LOW There is limited evidence and the assessment should be treated cautiously. Do not use numerical confidence or skill ratings. Do not exaggerate confidence merely because the subject has discussed a subject frequently. INTEREST IS NOT CAPABILITY Interest in a subject does not establish knowledge or capability. A subject asking many questions about a subject may indicate interest. Only assess knowledge or capability when the interactions provide evidence for it. For example: BAD: "The subject has strong knowledge of architecture because they frequently ask questions about building houses." BETTER: "The subject demonstrates sustained interest in residential construction, but available interactions provide insufficient evidence to assess practical construction capability." If other discussions demonstrate detailed understanding and application of construction principles, then a capability assessment may be appropriate. WORKING CHARACTERISTICS Identify professionally relevant working characteristics only where meaningful evidence exists. Technical familiarity, job title, tenure and technical scope are not working characteristics. "Long-time Linux user" belongs under knowledge or experience; "backend systems orientation" describes technical scope; "large-scale environment experience" belongs under experience. Assess ways of working from relevant interactions or explicit statements, not from these labels. Leave working_characteristics empty when supporting evidence is absent. Examples may include: * analytical reasoning * pragmatism * attention to detail * communication * independence * persistence * creativity * systematic problem solving * risk awareness * willingness to challenge assumptions * ability to learn unfamiliar subjects These are examples only. Avoid personality diagnosis. Describe observable professional tendencies rather than making psychological claims. UNCERTAINTY AND LIMITATIONS Absence of evidence is important. If there is insufficient information to assess something potentially relevant, state that uncertainty where useful. Do not fill gaps with assumptions. Do not interpret lack of discussion about a subject as evidence that the subject lacks that capability. For example: GOOD: "There is insufficient evidence to assess people-management experience." BAD: "The subject has weak people-management skills." The second conclusion is unsupported if the subject simply has not been discussed. CROSS-DOMAIN CAPABILITY Capabilities may be useful outside the context in which they were acquired. Capture the underlying capability accurately without trying to determine which jobs it could apply to. For example, someone may demonstrate: * software engineering capability * residential construction knowledge * financial understanding * project planning ability These should all be represented if sufficiently supported. Do NOT recommend occupations or speculate about career changes. matched.to performs role matching separately. ASSESSMENT TITLE Create a concise title that characterizes the strongest and most relevant findings in the assessment. The title is descriptive; it is not necessarily the subject's current or previous job title and must not recommend a future job. QUALIFICATIONS Include degrees, certifications, licences, completed courses, apprenticeships or other formal qualifications only when supported by available information. Do not infer a qualification from demonstrated capability. Preserve whether the qualification is supported, self-reported, conflicting or otherwise unknown. STABLE IDENTIFIERS Assign a short, descriptive and globally unique id to every domain, capability, knowledge item, experience claim, qualification, working characteristic, interest, uncertainty, evidence item and occupational concept. IDs must begin with a lowercase letter and contain only lowercase letters, digits, underscores and hyphens. They exist only to create stable references within the assessment. An evidence ID identifies one embedded evidence entry, not the source statement. The same source statement may support several findings, but every occurrence must have its own evidence ID. Use the containing finding ID followed by _ev1, _ev2, etc. For example, cap_dom1_1_ev1 and know_dom1_1_ev1 may describe the same source statement but must never share an ID. Number evidence locally within each finding; do not maintain one global evidence counter. Use distinct finding prefixes such as dom1, cap_dom1_1, know_dom1_1, exp1, qual1, work1, interest1, uncertainty1 and concept1. These are identifier examples, not new schema fields. OCCUPATIONAL CONCEPTS After completing the evidence-aware assessment, identify findings that describe an occupationally relevant: * skill * body of knowledge * competence * occupation * qualification Represent these findings in occupational_concepts. This collection is the explicit input surface for downstream occupational-taxonomy mapping. The assessment itself is taxonomy-neutral: * Do not look up or emit ESCO, O*NET or other taxonomy identifiers. * Do not force labels to match a known taxonomy label. * Use a concise natural-language label and a standalone description of what the subject knows, does, has done or holds. * Create separate concepts for independently classifiable ideas. For example, "Python and PostgreSQL" should normally be two concepts. * Every concept must cite one or more source_refs. Each source reference must be the ID of a capability, knowledge item, experience claim, qualification or working characteristic in this assessment. * Do not reference domains, evidence items, interests, uncertainties or other occupational concepts. * Do not create a possessed occupational concept from interest alone. * Do not create concepts for unsupported possibilities or topics listed only as uncertainties. Use importance "core" when the concept is central to the subject's occupational assessment. Use "supporting" when it remains meaningful but is not central. Do not decide whether a concept is mappable. A downstream classifier is responsible for mapping or preserving it as unresolved metadata. EXAMPLES EXAMPLE 1 -- TECHNICAL CAPABILITY BAD: "Python: 9/10" GOOD: { "id": "cap_python_development", "name": "Python software development", "assessment": "Demonstrates substantial practical knowledge of Python, including application architecture, debugging, dependency management and API development.", "level": "advanced", "confidence": "high", "professional_experience": "unknown", "evidence": [ { "id": "ev_python_discussions", "type": "demonstrated", "description": "Repeated technical discussions demonstrate detailed practical reasoning about Python application development and production problems." } ] } EXAMPLE 2 -- SELF-REPORTED EXPERIENCE The subject has stated that they led a large cloud migration. BAD: "The subject successfully led a large cloud migration." GOOD: { "id": "exp_cloud_migration", "claim": "Led a large cloud migration.", "professional": true, "verification_status": "unverified", "evidence": [ { "id": "ev_cloud_migration_report", "type": "self_reported", "description": "The subject states that they were responsible for leading a large cloud migration." } ] } EXAMPLE 3 -- SUPPORTING OBSERVATION The subject claims substantial production engineering experience and has repeatedly demonstrated detailed knowledge of production systems. GOOD: { "id": "exp_production_systems", "claim": "Has substantial experience operating production systems.", "professional": true, "verification_status": "unverified", "evidence": [ { "id": "ev_production_experience_report", "type": "self_reported", "description": "The subject describes substantial responsibility for production systems." }, { "id": "ev_production_experience_support", "type": "supporting_observation", "description": "The subject demonstrates detailed understanding of production incidents, observability, capacity constraints and failure mitigation. This supports the plausibility of the claim but does not independently verify the employment history." } ] } EXAMPLE 4 -- NON-PROFESSIONAL CAPABILITY A subject works professionally in software but has extensively discussed building their own house, including planning, materials, drainage, structural decisions and coordination of work. GOOD: { "id": "cap_construction_planning", "name": "Residential construction planning", "assessment": "Demonstrates meaningful practical understanding of residential construction planning, material selection, sequencing and problem solving.", "level": "working", "confidence": "high", "professional_experience": "no", "evidence": [ { "id": "ev_construction_reasoning", "type": "demonstrated", "description": "Extensive discussions demonstrate practical reasoning about construction methods, materials, sequencing and tradeoffs." }, { "id": "ev_house_build_report", "type": "self_reported", "description": "The subject states that this knowledge has been applied while building their own house." } ] } This capability should be included even though it is unrelated to the subject's primary profession. EXAMPLE 5 -- INTEREST WITHOUT SUFFICIENT CAPABILITY EVIDENCE BAD: { "name": "Investment analysis", "assessment": "Strong", "confidence": "high", "professional_experience": "unknown", "evidence": [ { "type": "demonstrated", "description": "The subject frequently asks about investing." } ] } BETTER: Represent investing as an interest if the available interactions demonstrate interest but do not provide sufficient evidence of investment-analysis capability. EXAMPLE 6 -- UNKNOWN BAD: { "name": "People management", "assessment": "Limited", "confidence": "low" } GOOD: { "id": "unc_people_management", "topic": "People management", "description": "Available interactions do not provide sufficient evidence to assess the subject's people-management experience or capability." } EXAMPLE 7 -- TAXONOMY-NEUTRAL OCCUPATIONAL CONCEPT GOOD: { "id": "occ_python_development", "type": "skill", "label": "Python software development", "description": "Developing and maintaining production software in Python, including application structure, debugging and API implementation.", "source_refs": ["cap_python_development"], "importance": "core" } BAD: { "label": "Python (computer programming)", "esco_uri": "http://data.europa.eu/esco/skill/example" } The bad example attempts to perform taxonomy mapping inside the assessment. ASSESSMENT QUALITY Prefer a smaller number of meaningful, well-supported observations over a large number of weak or speculative ones. Do not attempt to maximize the number of domains, capabilities or knowledge items. Do not create superficial capabilities from isolated interactions. Preserve nuance in the assessment text. The structured fields exist to make the assessment interpretable and searchable. They are not a substitute for explaining why an assessment was made. GENERATION Perform the assessment analysis before beginning the final JSON output. Determine the title, relevant domains, capabilities, knowledge, experience, qualifications, evidence, levels, confidence, working characteristics, interests, uncertainties and occupational concepts before generating the final assessment. Do not expose chain-of-thought, internal reasoning, drafts, partial assessments or intermediate JSON. If your interface supports performing analysis without displaying intermediate output, use that capability. While the assessment is being prepared, if your interface supports a loading state, progress indicator, status display or similar mechanism, prefer that instead of visibly streaming the assessment contents. A simple status such as: Creating assessment... is sufficient. Do not provide detailed progress commentary. Once the assessment is complete, proceed directly to the final JSON output. OUTPUT Return the completed matched.to Assessment Report directly in this conversation as valid JSON conforming exactly to the response schema below. The subject will copy the JSON from this conversation and paste it into matched.to. COPYABILITY AND PRESENTATION The assessment is primarily machine-readable data. The subject does not need to read the complete JSON in the conversation. If your interface supports presenting long structured output in a contained, scrollable, collapsible, artifact-style or otherwise compact block, use that presentation. Prefer a presentation that: * keeps the complete JSON together * provides a copy control when supported * avoids requiring the subject to scroll through the entire assessment * keeps the surrounding conversation easy to use If your interface supports a dedicated copyable code or text block, use it. Otherwise, present the assessment as one fenced Markdown `json` code block. The entire assessment MUST appear as one contiguous JSON document. Do not split the JSON across multiple blocks or messages. Do not insert commentary, status messages or explanations inside the JSON. Do not intentionally convert the JSON to a single line merely to make it copyable. Preserve normal readable JSON formatting unless the interface itself handles presentation differently. COMPLETENESS AND SIZE The returned JSON MUST be complete and syntactically valid. Never allow the JSON to be truncated because of output or context limits. Before beginning the final JSON output, determine whether the complete assessment will fit within your available output limits. If necessary, reduce the size of the assessment before responding. When reducing size, preserve the most professionally relevant and well-supported information. Remove or compress information in approximately this order: 1. Repetitive evidence describing the same capability. 2. Low-confidence observations with limited professional relevance. 3. Minor interests with little demonstrated capability. 4. Redundant capabilities or knowledge that can be represented by a broader item. 5. Less significant domains with weak evidence. Prefer concise evidence descriptions over removing important capabilities. Never remove information merely to make the subject appear stronger. Always preserve: * important limitations and uncertainties * significant contradictory evidence * distinctions between demonstrated, inferred and self-reported information * occupational concepts for important supported findings * validity of the response schema A smaller complete assessment is always preferable to a larger truncated assessment. Do not begin emitting the final JSON until you can complete the entire JSON object within your available output limits. OPTIONAL FILE If your interface supports file creation, you may additionally provide the same assessment as a JSON file. A file is optional and MUST NOT replace the JSON shown directly in the conversation. The JSON shown in the conversation is the canonical output. FINAL VALIDATION Before producing the final JSON, verify that: 1. Every substantive assessment has supporting evidence. 2. Self-reported history has not been represented as independently verified. 3. Demonstrated capability has not automatically been represented as professional experience. 4. Interest has not been represented as capability without sufficient evidence. 5. Lack of evidence has not been interpreted as lack of ability. 6. Relevant capabilities outside the subject's profession have been included. 7. No occupations or jobs have been recommended. 8. No evidence has been invented. 9. Confidence levels reflect the strength of available evidence. 10. Assessment levels are conservative and independent of confidence. 11. All IDs are globally unique. 12. Every occupational concept references only eligible findings in this assessment. 13. Interests and uncertainties have not been represented as possessed occupational concepts. 14. No taxonomy-specific identifier or asserted taxonomy mapping appears in the assessment. 15. The JSON is syntactically valid. 16. The JSON conforms exactly to the matched.to Assessment Report schema. 17. The complete JSON is present, has not been truncated and does not exceed 200,000 UTF-8 encoded bytes. RESULT CONTRACT Use assessment_version "3.1.0". For status "success", assessment must contain an assessment object and error must be null. For status "error", assessment must be null and error must contain the schema-defined error object. Never return both objects or both null. These are mandatory specification rules, validated by consumers in addition to JSON Schema. Every qualification includes issuer and year. Use null when either is unknown; never invent an issuer or date to fill these fields. All source_refs within one concept must be distinct. A qualification concept must reference at least one formal qualification. All finding and evidence IDs must be globally unique. Invalid IDs and references must be corrected by the generating model; consumers must not silently rename IDs or rewrite findings. RESPONSE SCHEMA Return ONLY a JSON object conforming to the following JSON Schema inside the single assessment block described above. Do not return this schema itself. { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://schemas.matched.to/assessment/v3.1.0", "title": "matched.to Assessment Result", "description": "A taxonomy-neutral assessment of a subject. occupational_concepts identifies findings that downstream systems may align with ESCO, O*NET, or another occupational taxonomy. Concept IDs and labels from any particular taxonomy do not belong in this document. All IDs within an assessment must be globally unique. Every occupational_concepts.source_refs value must resolve to a capability, knowledge item, experience claim, qualification, or working characteristic in the same assessment. Those cross-reference rules and the UTF-8 request-size limit must be enforced outside JSON Schema. Result consistency (success requires an assessment and null error; error requires null assessment and an error), duplicate source references, and qualification-concept references to formal qualifications are application-level invariants. Qualification issuer and year are required keys with null values when unknown.", "type": "object", "additionalProperties": false, "required": [ "assessment_version", "status", "assessment", "error" ], "properties": { "assessment_version": { "type": "string", "const": "3.1.0" }, "status": { "type": "string", "enum": [ "success", "error" ] }, "assessment": { "anyOf": [ { "$ref": "#/$defs/assessment" }, { "type": "null" } ] }, "error": { "anyOf": [ { "$ref": "#/$defs/error" }, { "type": "null" } ] } }, "$defs": { "id": { "type": "string", "pattern": "^[a-z][a-z0-9_-]{0,63}$", "description": "Unique identifier for one object within the assessment. Every embedded evidence entry has its own ID, even when the same source statement supports multiple findings. Evidence IDs may use the containing finding ID followed by _ev1, _ev2, etc." }, "nonEmptyString": { "type": "string", "minLength": 1, "maxLength": 4000 }, "shortString": { "type": "string", "minLength": 1, "maxLength": 200 }, "confidence": { "type": "string", "description": "Confidence that the assessment finding is supported, not the subject's proficiency.", "enum": [ "low", "medium", "high" ] }, "level": { "type": "string", "description": "Assessed depth or practical proficiency. This is independent of confidence.", "enum": [ "foundational", "working", "advanced", "expert", "unknown" ] }, "professionalExperience": { "type": "string", "enum": [ "yes", "no", "unknown" ] }, "verificationStatus": { "type": "string", "enum": [ "supported", "unverified", "conflicting", "unknown" ] }, "evidenceType": { "type": "string", "enum": [ "demonstrated", "self_reported", "inferred", "supporting_observation" ] }, "errorCode": { "type": "string", "enum": [ "missing_source", "empty_source", "unsupported_source", "unreadable_source", "insufficient_source_data" ] }, "error": { "type": "object", "additionalProperties": false, "required": [ "code", "message" ], "properties": { "code": { "$ref": "#/$defs/errorCode" }, "message": { "$ref": "#/$defs/nonEmptyString" } } }, "assessment": { "type": "object", "additionalProperties": false, "required": [ "title", "summary", "domains", "experience_claims", "qualifications", "working_characteristics", "interests", "uncertainties", "occupational_concepts" ], "properties": { "title": { "$ref": "#/$defs/assessmentTitle" }, "summary": { "$ref": "#/$defs/summary" }, "domains": { "type": "array", "maxItems": 30, "items": { "$ref": "#/$defs/domain" } }, "experience_claims": { "type": "array", "maxItems": 50, "items": { "$ref": "#/$defs/experienceClaim" } }, "qualifications": { "type": "array", "maxItems": 50, "items": { "$ref": "#/$defs/qualification" } }, "working_characteristics": { "type": "array", "maxItems": 30, "items": { "$ref": "#/$defs/workingCharacteristic" } }, "interests": { "type": "array", "maxItems": 30, "items": { "$ref": "#/$defs/interest" } }, "uncertainties": { "type": "array", "maxItems": 30, "items": { "$ref": "#/$defs/uncertainty" } }, "occupational_concepts": { "description": "A taxonomy-neutral index of occupationally relevant findings. Include only skills, knowledge, competences, occupations, and qualifications supported elsewhere in this assessment. Interests alone must not be represented as possessed occupational concepts.", "type": "array", "maxItems": 300, "items": { "$ref": "#/$defs/occupationalConcept" } } } }, "summary": { "type": "object", "additionalProperties": false, "required": [ "characterization", "notable_strengths", "limitations" ], "properties": { "characterization": { "$ref": "#/$defs/nonEmptyString" }, "notable_strengths": { "type": "array", "maxItems": 10, "items": { "$ref": "#/$defs/nonEmptyString" } }, "limitations": { "type": "array", "maxItems": 10, "items": { "$ref": "#/$defs/nonEmptyString" } } } }, "evidence": { "type": "object", "additionalProperties": false, "required": [ "id", "type", "description" ], "properties": { "id": { "$ref": "#/$defs/id" }, "type": { "$ref": "#/$defs/evidenceType" }, "description": { "$ref": "#/$defs/nonEmptyString" } } }, "capability": { "type": "object", "additionalProperties": false, "required": [ "id", "name", "assessment", "level", "confidence", "professional_experience", "evidence" ], "properties": { "id": { "$ref": "#/$defs/id" }, "name": { "$ref": "#/$defs/shortString" }, "assessment": { "$ref": "#/$defs/nonEmptyString" }, "level": { "$ref": "#/$defs/level" }, "confidence": { "$ref": "#/$defs/confidence" }, "professional_experience": { "$ref": "#/$defs/professionalExperience" }, "evidence": { "type": "array", "minItems": 1, "maxItems": 20, "items": { "$ref": "#/$defs/evidence" } } } }, "knowledge": { "type": "object", "additionalProperties": false, "required": [ "id", "subject", "assessment", "level", "confidence", "evidence" ], "properties": { "id": { "$ref": "#/$defs/id" }, "subject": { "$ref": "#/$defs/shortString" }, "assessment": { "$ref": "#/$defs/nonEmptyString" }, "level": { "$ref": "#/$defs/level" }, "confidence": { "$ref": "#/$defs/confidence" }, "evidence": { "type": "array", "minItems": 1, "maxItems": 20, "items": { "$ref": "#/$defs/evidence" } } } }, "domain": { "type": "object", "additionalProperties": false, "required": [ "id", "name", "summary", "confidence", "capabilities", "knowledge" ], "properties": { "id": { "$ref": "#/$defs/id" }, "name": { "$ref": "#/$defs/shortString" }, "summary": { "$ref": "#/$defs/nonEmptyString" }, "confidence": { "$ref": "#/$defs/confidence" }, "capabilities": { "type": "array", "maxItems": 50, "items": { "$ref": "#/$defs/capability" } }, "knowledge": { "type": "array", "maxItems": 50, "items": { "$ref": "#/$defs/knowledge" } } } }, "experienceClaim": { "type": "object", "additionalProperties": false, "required": [ "id", "claim", "professional", "verification_status", "evidence" ], "properties": { "id": { "$ref": "#/$defs/id" }, "claim": { "$ref": "#/$defs/nonEmptyString" }, "professional": { "type": "boolean" }, "verification_status": { "$ref": "#/$defs/verificationStatus" }, "evidence": { "type": "array", "minItems": 1, "maxItems": 20, "items": { "$ref": "#/$defs/evidence" } } } }, "qualification": { "type": "object", "additionalProperties": false, "required": [ "id", "name", "kind", "issuer", "year", "verification_status", "evidence" ], "properties": { "id": { "$ref": "#/$defs/id" }, "name": { "$ref": "#/$defs/shortString" }, "kind": { "type": "string", "enum": [ "degree", "certification", "licence", "course", "apprenticeship", "other" ] }, "issuer": { "anyOf": [ { "$ref": "#/$defs/shortString" }, { "type": "null" } ] }, "year": { "type": [ "integer", "null" ], "minimum": 1900, "maximum": 9999 }, "verification_status": { "$ref": "#/$defs/verificationStatus" }, "evidence": { "type": "array", "minItems": 1, "maxItems": 20, "items": { "$ref": "#/$defs/evidence" } } } }, "workingCharacteristic": { "type": "object", "additionalProperties": false, "required": [ "id", "name", "assessment", "confidence", "evidence" ], "properties": { "id": { "$ref": "#/$defs/id" }, "name": { "$ref": "#/$defs/shortString" }, "assessment": { "$ref": "#/$defs/nonEmptyString" }, "confidence": { "$ref": "#/$defs/confidence" }, "evidence": { "type": "array", "minItems": 1, "maxItems": 20, "items": { "$ref": "#/$defs/evidence" } } } }, "interest": { "type": "object", "additionalProperties": false, "required": [ "id", "name", "description", "confidence", "evidence" ], "properties": { "id": { "$ref": "#/$defs/id" }, "name": { "$ref": "#/$defs/shortString" }, "description": { "$ref": "#/$defs/nonEmptyString" }, "confidence": { "$ref": "#/$defs/confidence" }, "evidence": { "type": "array", "minItems": 1, "maxItems": 20, "items": { "$ref": "#/$defs/evidence" } } } }, "uncertainty": { "type": "object", "additionalProperties": false, "required": [ "id", "topic", "description" ], "properties": { "id": { "$ref": "#/$defs/id" }, "topic": { "$ref": "#/$defs/shortString" }, "description": { "$ref": "#/$defs/nonEmptyString" } } }, "occupationalConcept": { "type": "object", "additionalProperties": false, "required": [ "id", "type", "label", "description", "source_refs", "importance" ], "properties": { "id": { "$ref": "#/$defs/id" }, "type": { "description": "The broad kind of occupational concept, not a taxonomy-specific classification.", "type": "string", "enum": [ "skill", "knowledge", "competence", "occupation", "qualification" ] }, "label": { "$ref": "#/$defs/conceptLabel" }, "description": { "$ref": "#/$defs/conceptDescription" }, "source_refs": { "description": "IDs of capabilities, knowledge items, experience claims, qualifications, or working characteristics that support this concept. References must not point to domains, evidence items, interests, uncertainties, or other occupational concepts.", "type": "array", "minItems": 1, "maxItems": 20, "items": { "$ref": "#/$defs/id" } }, "importance": { "description": "Importance to the occupational assessment. This is neither proficiency nor mapping confidence.", "type": "string", "enum": [ "core", "supporting" ] } } }, "assessmentTitle": { "type": "string", "minLength": 1, "maxLength": 200, "description": "A concise title derived from the assessment, not a claimed formal occupation." }, "conceptLabel": { "type": "string", "minLength": 1, "maxLength": 200, "description": "A concise source-language label. It need not match a preferred label in any taxonomy." }, "conceptDescription": { "type": "string", "minLength": 1, "maxLength": 4000, "description": "A standalone explanation of what is being classified. Do not insert a taxonomy definition." } } } FINAL MESSAGE After the complete JSON assessment block, output exactly the following message as the final message in your response: Copy the JSON assessment above and paste it into matched.to. Do not include any other text after this message.