Field-Aware Default Resolution: Deterministic Behavior When Fields Are Absent

Mechanism

Default resolution is implemented as a phase of agent instantiation that occurs after schema validation and before identity finalization. When a candidate agent specification is presented to the platform, the schema validator first confirms that every present field conforms to its declared type and that no field is present in a form forbidden by the schema. The default resolver then walks the schema in canonical order, identifies each field that is absent in the specification, and applies the schema's declared default for that field.

Defaults are typed and lineage-bound. A schema default is not a literal value attached to a field declaration; it is a typed expression that the platform evaluates against the candidate agent's instantiation context — which includes the platform epoch, the parent lineage if any, and the instantiation principal — and which produces a value whose type matches the field's declared type. The evaluation is deterministic: given the same schema, the same candidate specification, and the same instantiation context, every conforming platform produces the same resolved values and records the same lineage entries.

Each resolution is recorded as a distinct entry in the agent's append-only lineage. The entry names the field, the schema version under which the default was declared, the default expression's content-anchored identifier, the inputs the expression consumed from the instantiation context, and the resolved value. The entry is committed before the agent's identity is finalized, so that the agent's identity hash transitively commits to the resolved values and to the path by which they were resolved. After identity finalization, the resolved values are immutable: no runtime path may re-resolve a field that was resolved at instantiation, and no runtime path may treat a field as absent that was resolved as present.

The schema declares, for each field, one of three default classes. A literal default resolves to a fixed value declared in the schema. A computed default resolves to the value of a typed expression evaluated against the instantiation context. A structural default resolves to a value determined by the absence itself: an absent mutation descriptor structurally resolves the agent to immutable, an absent memory field structurally resolves to a blank trace, and an absent intent field structurally resolves by walking the parent lineage to the nearest ancestor with an explicit intent. Structural defaults are not configurable at the schema level beyond their declared kind; they are the platform's commitment to a stable interpretation of absence.

Default resolution is audit-required. Every lineage entry produced by the resolver is flagged for inclusion in the agent's audit surface, and any audit query asking "what was this field at instantiation?" or "why did this field have this value?" is answered directly from the lineage without consulting runtime state. Because the resolver runs once per instantiation and the resulting entries are immutable, the audit answer is stable for the lifetime of the agent and for any derivative agent that inherits its lineage.

Operating Parameters

The mechanism is parameterized along three axes that schema authors and platform operators tune to deployment needs without altering the structural commitment to instantiation-time resolution. Schema versioning is the primary axis: a schema declares a version, and an agent's instantiation lineage records the schema version under which its defaults were resolved. Subsequent schema versions may add fields, narrow types, or change defaults, but they may not retroactively alter the resolution of agents instantiated under prior versions; the platform binds each agent to the schema version present at its instantiation.

Default expression expressiveness is the second axis. The reference implementation uses a deterministic, side-effect-free expression language that may reference fields of the candidate specification, fields of the parent lineage, and a small set of platform-supplied context values such as the instantiation epoch and the principal identifier. Expressions that consult external services, depend on wall-clock time outside the epoch granularity, or otherwise introduce non-determinism are rejected at schema compile time. This ensures that default resolution is reproducible across heterogeneous platforms and across time.

Audit granularity is the third axis. The platform records, at minimum, the field name, the schema version, the default expression identifier, and the resolved value for each resolution event; operators may configure the platform to additionally record the full evaluation trace, including intermediate values, for high-assurance deployments. The minimum granularity is sufficient to verify that the resolution was correct given the schema and context; the extended granularity is sufficient to reproduce the evaluation step by step.

Resolution is bounded in cost by the schema size and the depth of parent lineage walks for structural defaults. For schemas of practical size — dozens to hundreds of fields — and lineage depths bounded by platform policy, resolution completes in a small constant time relative to instantiation overhead and is not a bottleneck for agent creation.

Alternative Embodiments

The mechanism admits several embodiments that preserve the structural commitment while accommodating schema-design and deployment variation. In a strict embodiment, every field of the schema must declare a default, and the resolver refuses any candidate specification whose absent fields lack declared defaults; this is appropriate for high-assurance deployments where unresolved absence must be impossible. In a permissive embodiment, fields may be declared without defaults, and the resolver records absent-without-default as a distinct lineage entry that downstream consumers may treat according to their own policy.

In a structural-only embodiment, all defaults are structural rather than literal or computed; this maximizes the platform's commitment to a stable interpretation of absence at the cost of expressive flexibility. In a hybrid embodiment, schemas mix literal, computed, and structural defaults according to the field's semantic role, with structural defaults reserved for fields whose interpretation must be stable across schema versions.

In an inherited embodiment, an agent's defaults may be partially inherited from a parent agent's lineage, with the schema declaring which fields are inherited and which are resolved fresh; the lineage records the inheritance source for each inherited field. In a delegated embodiment, certain default expressions may consult a designated authority during instantiation, with the authority's response and signature recorded in lineage; this permits defaults that depend on policy state external to the schema while preserving the audit guarantee.

In a versioned-default embodiment, a single schema field may declare multiple defaults indexed by schema version, and the resolver selects the default corresponding to the schema version under which the agent is being instantiated. This permits schema evolution that changes default semantics for new agents without altering the historical resolutions of existing agents.

Composition With Adjacent Mechanisms

Default resolution composes with the broader semantic agent architecture along several seams. The structural validator that runs prior to default resolution ensures that present fields are well-formed; the default resolver runs only after validation succeeds, so that defaults are never applied over malformed input. The identity finalizer that runs after default resolution computes the agent's content-anchored identity over the union of present and resolved fields, so that an agent's identity transitively commits to every field, present or defaulted.

Composition with the lineage mechanism is via the resolution entries: each entry is a first-class lineage record subject to the same tamper-evidence guarantees as any other lineage record, and the lineage chain that includes resolution entries is the same chain that records subsequent agent state transitions. Composition with the audit mechanism is direct: the audit surface includes resolution entries by default, and audit queries about field provenance traverse the same structures as audit queries about state provenance.

Composition with the schema versioning mechanism is via the schema-version field of each resolution entry: an audit query can determine, for any agent, which schema version governed its instantiation, and a verifier can reproduce the resolution by re-evaluating the named expression against the recorded context. Composition with the parent-lineage mechanism is via structural defaults that walk parent lineages: an absent-intent field resolves by traversing the lineage until an explicit intent is found, and the traversal path is recorded in the resolution entry so that the answer is verifiable without re-walking the lineage.

Composition with the immutability mechanism is by construction: because resolution occurs before identity finalization and is recorded in lineage, the resolved values are part of the agent's identity and cannot be altered without producing a different agent. The runtime has no path by which a previously resolved field can be re-evaluated, and this is enforced at the schema layer rather than by runtime convention.

Prior-Art Distinction

Conventional approaches to absent-field handling fall into three families, each of which the mechanism distinguishes itself from along structural rather than incremental lines. The first family is runtime defaults applied lazily: the framework treats absent fields as null and substitutes a default value the first time the field is accessed. Lazy defaults produce non-deterministic agent behavior because the default applied may depend on access order, framework version, or runtime configuration, and they leave no audit trail attesting to which default was applied or when. The mechanism here resolves at instantiation, records the resolution in lineage, and forecloses runtime re-resolution.

The second family is convention-based defaults: the framework documents that certain absent fields should be interpreted in certain ways and relies on consumers to honor the convention. Convention-based defaults break across framework boundaries and across version boundaries, because a consumer that does not share the convention will interpret absence differently. The mechanism here makes the default a property of the schema rather than the framework, so that any conforming platform produces the same resolution.

The third family is external configuration that supplies defaults at deployment time: an operator-supplied configuration map provides values for fields the agent specification does not name. External configuration introduces a deployment-state dependency that is not bound to the agent's identity, so that the same agent specification deployed under different configurations is, in practice, different agents whose differences are not visible from their identity hashes. The mechanism here makes resolved defaults part of the agent's identity, so that two agents with identical identity necessarily had identical resolutions.

Disclosure Scope

The disclosure encompasses the resolution of absent schema fields at agent instantiation by deterministic evaluation of typed default expressions or by application of structural defaults whose meaning is the platform's stable interpretation of absence; the recording of each resolution as an audit-required entry in the agent's append-only lineage; the structural binding of resolved values into the agent's content-anchored identity; and the foreclosure of runtime re-resolution after identity finalization.

The disclosure encompasses the strict, permissive, structural-only, hybrid, inherited, delegated, and versioned-default embodiments described above, as well as additional embodiments differing in expression-language selection, lineage-record layout, or audit granularity without departing from the structural construction. It is not limited to specific schema languages, hash primitives, or default-expression dialects, and it is not limited to any particular agent runtime, substrate, or deployment topology.