KFD-12: Software work must keep Initiative and Assignment distinct
- Status: draft
- Number: 12
- Kind: principle
- Applies to: any adopting software-development Domain Profile that organizes durable human and agent work across execution, review, and continuation
One sentence
Software work must keep Initiative, Assignment, occurrence, Claim, Assessment, Decision, Admission, and continuation independently inspectable.
Scope
KFD-12 is the first numbered software-development application of the Fact-Episode Ontology and Action Responsibility Geometry. It is not a universal workflow for every domain. Finance, healthcare, research, household work, or other domains may define different Domain Profiles, vocabulary, lifecycle, evidence, and settlement rules while preserving the KFD responsibilities they claim to adopt.
Responsibility lifecycle
The software work model separates:
Initiative
-> Assignment
-> Episode of realized work
-> completion or progress claim
-> purpose-bound assessment
-> authorized decision
-> independently recorded admission result
-> continuation, settlement, or successor responsibility
These are decision roles, not a mandated count of files, records, APIs, commands, screens, or services.
| Role | Responsibility |
|---|---|
| Initiative | Preserves an independently addressable context for continuing coordinated work: coordination purpose, scope, participants, relevant Pursuits, Assignment relations, lineage, and settlement policy. |
| Assignment | Preserves an independently addressable bounded responsibility proposed to, accepted by, or held by a participant: holder, accepted responsibility, Initiative and Pursuit roots, exact Atlas and Warrant roots, acceptance boundary, evidence obligations, settlement policy, and typed lineage. |
| Episode | Preserves what actually occurred. |
| Claim | States progress, completion, artifact, or consequence without self-certifying it. |
| Assessment | Evaluates a claim for a declared purpose under KFD-2 trust semantics. |
| Decision | Accepts, rejects, requests evidence, pauses, reopens, or otherwise disposes of responsibility under a Warrant. |
| Admission | Records whether the Decision’s requested effect entered the owning state authority and identifies the successor Fact cut only on success. |
| Continuation | Creates or updates the next bounded responsibility while preserving lineage. |
Occurrence does not imply a valid claim. A claim does not imply a passing Assessment. Assessment does not grant authority. Decision does not imply Admission, and neither erases the Episode or evidence boundary on which it relied.
Software profile vocabulary
KFD-12 names the first two software-domain roles Initiative and Assignment:
Initiative -> continuing coordinated work context
Assignment -> bounded responsibility proposed to, accepted by, or held by a participant
An Initiative carries a coordination-purpose summary but does not become the authority for intended-change semantics. It may reference one or more Pursuits, but it is not identical to Pursuit, a repository, or a project. An Assignment may be proposed, accepted, refused, revised, continued, or settled, but it is not identical to a task, objective, Warrant, Episode, or claim. Its accepted responsibility and settlement conditions must not silently redefine its Pursuits. These names are canonical within this software Domain Profile; they do not bind other domains.
Gate
A conforming software Domain Profile:
- declares its mapping to Fact, Episode, Atlas, Pursuit, and Warrant;
- gives every Initiative and Assignment stable identity, explicit state, and inspectable lineage;
- keeps Assignment acceptance distinct from proposal, authority, occurrence, claim, and settlement;
- makes every accepted claim traceable to occurrence and admitted evidence;
- distinguishes assessment purpose from authorization to decide;
- records Admission separately from Decision and publishes a successor Fact cut only when Admission succeeds;
- preserves parent, child, dependency, revision, and continuation lineage;
- keeps denial, missing evidence, residual risk, and unresolved responsibility visible;
- provides a low-friction projection for simple work without fabricating or fusing decision roles;
- states explicitly that its workflow is domain-owned rather than universal.
Adopter witness and activation boundary
A conforming software Domain Profile publishes a versioned witness that keeps Initiative and Assignment identity and responsibility separate, records Assignment proposal and acceptance independently, binds exact Pursuit, Atlas, and Warrant roots, preserves continuation lineage, and proves that its simple session projection round-trips without fusing roles.
The machine interface is
schemas/kfd-12/adopter-witness.schema.json.
Qualification and activation use the shared interfaces discovered through
activation-contracts.json. Structural or
single-implementation conformance does not activate this draft.
Relationship
KFD-7 defines Domain Profiles. KFD-8 through KFD-10 define the three action coordinates used here. KFD-11 defines the cross-domain path from Claim through Assessment and authorized Decision to Admission. KFD-12 translates those responsibilities into one software-development work model; it does not modify their cross-domain semantics.
The founding discovery changed perspective from the developer refining Fact, Episode, Pursuit, Atlas, and Warrant to the participant trying to get real software work done. From that participant view, more control over the lower objects did not answer which continuing work context mattered or which bounded responsibility had been accepted. KFD-4 exposed Initiative and Assignment; KFD-5 then qualified their distinct responsibilities. The live qualification case preserves that genesis and decision boundary. Acceptance of these two software-domain Primitives does not activate this draft KFD.
This decision previously occupied the pre-stable KFD-11 coordinate. The Foundation Revision maps that immutable prerelease lineage to KFD-12.
Non-claims
KFD-12 does not require every task to expose seven user-visible objects, require other domains to use Initiative or Assignment, prescribe Git, define one software methodology, or claim that other domains should copy this lifecycle.