<!-- normative -->

# Conflict Model

Conflict is broader than overlapping writes.

## Conflict types

Conflict types are defined in [Conflict types](glossary.md#conflict-types).

## Conflict record

```yaml
conflict:
  id: CONFLICT-001
  type: INTERFACE_CONFLICT
  parties:
    - NODE-012
    - NODE-019
  affected_resources:
    - "contract:customer-record-v3"
  severity: BLOCKING
  evidence_ids:
    - EVIDENCE-440
  resolution_authority: NODE-007
  resolution_policy: INTEGRATION_OWNER_ADJUDICATION
  lifecycle_state: OPEN
```

## Resolution policy

Every conflict type must define:

- whether it blocks execution, integration, publication, or acceptance;
- responsible authority;
- resolution procedure;
- required evidence;
- timeout or escalation policy, if applicable;
- invalidation consequences;
- permitted terminal states.

The deterministic control plane selects and applies the policy. Semantic resolution may be delegated to reasoning
components or people.

## Production, Integration, and Ownership

Shared mutable ownership should be avoided.

Prefer:

- Many contributors
- One integration owner
- One publishing authority
- One acceptance owner
- Immutable authoritative versions

### Roles

- Contributor: produces a candidate fragment.
- Integrator: combines candidate outputs.
- Publisher: declares an authoritative version.
- Contract owner: controls compatibility and change policy.
- Acceptance owner: accepts the integrated result.
- Consumer: binds to an immutable version or compatible version range.

### Artefact record

```yaml
artefact:
  id: ARTEFACT-001
  type: API_CONTRACT
  contract_owner: NODE-010
  contributors:
    - NODE-011
    - NODE-012
  integration_owner: NODE-013
  publisher: NODE-010
  acceptance_owner: NODE-010
  authoritative_version: 4
  content_hash: "..."
```

A mutable alias such as latest must be resolved to a concrete version before work begins.

### Repository integration semantics

For the first experiment, every writing attempt operates in an isolated executor sandbox containing a disposable
candidate worktree whose Git metadata is not shared with the authoritative repository and produces a candidate commit or
patch.

The integration owner performs integration in this deterministic order:

1. verify that the candidate diff is confined to the attempt's `owned_scope`;
2. reject an out-of-scope diff as `WRITE_CONFLICT`;
3. merge accepted candidate branches in ascending integration-action sequence;
4. classify a Git merge conflict as `WRITE_CONFLICT`;
5. run the fixed build, static-check, and visible test commands;
6. classify a clean merge that fails build, static checks, or tests as `INTERFACE_CONFLICT`;
7. record command outputs, exit codes, environment version, and resulting tree hash;
8. publish an immutable candidate artefact only after required checks pass.

A reasoning component is invoked only after a typed conflict has been recorded and deterministic resolution has failed
or policy specifically delegates semantic diagnosis.

Artefact contributor and integration-owner lists are derived projections of `PRODUCES_FOR` and `INTEGRATES` relations.
Relations are canonical.

### Incremental parent integration

For repository work, each decomposed parent owns an integration tree distinct from every child candidate tree.

When a mandatory child result becomes `ACCEPTED`, the parent schedules an `INTEGRATE` action. The integration action
applies that accepted child artefact to the parent's current published integration tree in deterministic integration
order. After integration and the required integration checks pass, the controller publishes a new immutable version of
the parent integration-tree artefact.

Each published integration-tree version records:

- its Git tree or commit identifier;
- the previous integration-tree version;
- the accepted child artefacts included in it;
- deterministic integration order;
- merge or application evidence;
- conflict evidence;
- validator bindings;
- content hash.

For repository work, a `DEPENDS_ON` obligation resolves to a `PUBLISHED` integration-tree version that includes every
accepted predecessor required by that obligation. That published version supplies the dependant action's `base_commit`.

A sibling dependant must not use an unintegrated child candidate branch as `base_commit`. It must not use the original
parent base after its required predecessor has been integrated. If no published integration-tree version includes all
required predecessors, the dependant remains `BLOCKED`.

Incremental integration does not imply parent acceptance. After all mandatory children are integrated, the parent still
requires parent-level validation and acceptance under [Parent acceptance](validation.md#parent-acceptance).