Model a job with immutable values

One useful idea

A class groups values and behavior under one name. A dataclass generates an initializer from declared fields; type annotations explain the intended types but do not validate incoming data. Use __post_init__ for runtime checks. In this kit, EvaluationJob requires schema version exactly integer 1, a canonical job identifier, a bounded prompt, a calendar-valid UTC timestamp and two distinct asset references. Boolean True is not a schema integer even though True == 1 in Python.

Frozen dataclasses refuse ordinary field assignment. They do not recursively freeze a list stored in a field. AssetRef is itself frozen and the job owns a tuple of exactly two AssetRef values. Both asset IDs and URI strings must differ. Together those immutable nested values prevent ordinary mutation through job.assets. This is value ownership, not a hostile-code security boundary or a file permission system.

A classmethod receives the class as cls. EvaluationJob.from_mapping reads an exact serialized dictionary, validates each nested asset, converts the input asset list to an owned tuple, then constructs cls. Unknown fields, duplicate IDs or locators, invalid text and invalid dates are refused rather than silently repaired. A URI is only a declared locator; accepting its spelling does not prove a file exists or decode a video.

to_dict returns fresh dictionaries and a fresh serialized asset list. asdict traverses the dataclasses; the serializer explicitly chooses a list because that is the external schema. Editing a returned mapping must not edit the immutable job or another serialization. FrozenInstanceError is an expected assignment refusal in this example. Do not broadly catch every exception: an unexpected programming fault should remain visible.

The starter supplies reviewed model and validation classes. Writing job_record composes that assistance; it does not prove you independently designed a domain model. Trace the reviewed class first, then build a small frozen value class of your own on changed inputs for the transfer task. Record exactly which validators and definitions you reused.

Refresh first: Domain-kit setup, Typed records and schema versions, Dictionaries and returned data.

Trace a finished example

from dataclasses import dataclass, FrozenInstanceError
import json
from pathlib import Path
from evalkit.model import EvaluationJob, identifier

# A small class definition: identifier is a disclosed reviewed validator.
@dataclass(frozen=True)
class NamedAsset:
    asset_id: str

    def __post_init__(self):
        identifier(self.asset_id)

example = NamedAsset("asset_demo")
print(example.asset_id)

source = json.loads(Path("fixtures/job.json").read_text(encoding="utf-8"))
job = EvaluationJob.from_mapping(source)
print(job.job_id, type(job.assets).__name__, len(job.assets))
serialized = job.to_dict()
serialized["assets"][0]["uri"] = "changed.mov"
print(job.assets[0].uri)
try:
    job.job_id = "changed"
except FrozenInstanceError:
    print("assignment refused")
source["schema_version"] = True
try:
    EvaluationJob.from_mapping(source)
except ValueError:
    print("boolean version refused")

The small NamedAsset class demonstrates the decorator, field annotation, self and post-initialization runtime check before the larger job model. NamedAsset("asset_demo") calls the generated initializer. The job then owns a tuple of frozen references; fresh serialization edits do not alter it. Assignment and boolean-version refusals have different causes; neither examines media.

The finished implementation is in evalkit/core.py. Reading it is guided practice, not independent evidence.

Change it, then build your own

One controlled change

Change the job ID and prompt, preserve the two different assets, then try the same URI for both assets and an impossible calendar date. Predict fresh output or ValueError before running.

Your independent task

Implement job_record in practice.py using the disclosed EvaluationJob class, returning its fresh serialized mapping. Do not import the finished core.job_record function. Test changed fields, exact schema/type refusals and ownership. Then author your own small frozen asset value class with a runtime validator; the supplied model tests alone cannot assess independent class design.

What success looks like

Build 1 checks changed typed fields, exact versions, nested ownership, distinct assets and declared validation boundaries. They are composition checks using reviewed model assistance, not an independent domain-model certificate or a media inspection.

Course help is guidance, not independent evidence. With JavaScript, opening help records guidance locally; otherwise note it in your README. Reset does not erase that history.

Repair a failed check

If source dictionaries change, stop retaining caller-owned nested containers. If a returned serialization changes the job, make fresh nested mappings. If bool passes as schema version, use the exact integer check. If a list remains inside a frozen value, distinguish shallow field freezing from immutable nested ownership.

NotImplementedError means a practice stub is still unfinished. Read the failing test name and the last error line. Change one behavior, rerun that build, then rerun all implemented builds.

Show it works on new inputs

Create a changed two-asset job and six refused cases, retaining actual results. Build your own small frozen value class and test initialization, ordinary assignment refusal and serialized ownership. Explain the difference between field freezing, type annotations and runtime validation, and disclose reviewed helpers.

Self-review: name the input, result, refused case and reason. Your local test output and explanation are separate from a quiz score; this page does not certify a pass.

Keep the idea

Model boundaries protect meaning and ownership. A well-formed job is a starting point, not proof that its media or supplied claims are true.