Lex Humanitas reveals where form hides power and replaces meaning.

Google Play Web App

Establishing the Logic of Programming/Creating the Subject in Entities

Goal

Establish an engineering contract: an individual computation within a system (job) is always an act belonging to a subject, not a “law of nature.”

1) Basic Invariant

J0: every record in jobs belongs to exactly one owner_id.

Infrastructure properties follow directly from J0:
– access to status and results is determined by the owner;
– deduplication is calculated within the boundaries of the owner;
– quotas, rate limiting, billing, and prioritization are calculated per owner;
– deletion, cancellation, and garbage collection of artifacts are tied to the owner;
– auditing becomes determinate: who initiated, repeated, forced, or stopped the action.

This is not a domain-level option, but the minimal ontology of responsibility for a multi-subject system.

2) Key Separation of Levels

2.1 Universal Executor (Worker Loop)

The executor may be entirely neutral:
– take a job from the queue;
– establish a lease;
– update the status;
– pass it to a handler.

This is the mechanism layer.

2.2 Job as an Act

A job is not a mechanism, but a request/ticket: an initiated action with a resource cost and consequences.

This is the responsibility layer.

Formula:
– the worker is universal;
– the job belongs to a subject.

The universality of the executor does not eliminate the subject-bound nature of the record in jobs.

3) Why “Owner Only in the Handler” Is Insufficient

If owner_id is absent from jobs and checked only in handlers, the infrastructure loses controllability:
– task creation and execution cannot be reliably restricted per subject at the queue level;
– load and cost cannot be accurately attributed to a subject;
– deduplication cannot be properly scoped to a subject;
– kill all jobs for owner cannot be performed quickly;
– tenant isolation cannot be strictly guaranteed in the queue’s core.

Result: subjectivity is displaced into “external logic,” where inconsistencies are inevitable.

4) Minimal Entity Model

For a universal computation system, jobs must contain:
– owner_id: the axis of access and responsibility;
– dedup_key (job_key): the axis of work identity;
– pipeline_version: the axis of result versioning.

These are infrastructure fields of a computational act, not fields of a particular domain.

5) Contract for the Source of Truth for Owner

Two correct modes are possible.

Option A (Normalization)

  • jobs.owner_id is the single source of truth;
  • transcriptions.owner_id is absent;
  • the owner of a derived entity is determined through ...job_id -> jobs.owner_id.

Option B (Pragmatic Denormalization)

  • jobs.owner_id is the single source of truth;
  • transcriptions.owner_id is a cached/derived field;
  • the application does not accept an external owner_id when creating or updating a derived entity;
  • the database prohibits mismatches where transcriptions.owner_id != jobs.owner_id.

Having two columns is permissible only when there is one source of truth and one derived field.

6) Database Invariants

  1. jobs.owner_id is NOT NULL + FK owners(id).
  2. Idempotency within a subject’s boundaries:
UNIQUE (owner_id, kind, pipeline_version, dedup_key)
WHERE dedup_key IS NOT NULL
  1. (For option B) prohibit owner mismatches between jobs and derived tables.

7) Service-Layer Contract

  1. Creating a job is always a subject-bound act:
  2. create_job(owner_id, kind, pipeline_version, dedup_key, payload...).
  3. Retrieving status/results always checks ownership:
  4. job.owner_id == requester.owner_id.
  5. Workers may remain universal, but resource accounting, limits, and auditing are performed by owner_id.

8) Migration Path Without “Blowing Up the Database”

  1. Add jobs.owner_id as temporarily nullable.
  2. Backfill from related tables (transcriptions, etc.).
  3. Change jobs.owner_id to NOT NULL.
  4. Add pipeline_version, dedup_key, and a partial unique index.
  5. Prevent mismatches for denormalized owner fields (trigger/constraint + code).

9) Quick Architecture Test

If the architecture is correct, the following questions can be answered at the jobs level, without “magic” in a handler:
– who initiated the job and who pays;
– how many resources a specific subject consumed;
– which jobs must be stopped for a particular subject;
– who has the right to see, repeat, or delete a result.

If these questions cannot be answered through jobs, subjectivity has not yet been established in the core.

10) Fundamental Conclusion

owner_id in jobs is not added complexity, but the restoration of responsibility to the system’s structure.

A system may have a universal execution mechanism, but every computational act within it must have an owner. Otherwise an “anonymous zone” emerges: a place where boundaries, limits, and responsibility leak away.

11) Ontological Clarification: The Subject Is Not an Epiphenomenon

The key principle:

The subject must not appear “somewhere in the middle.” The subject is not a derivative of the process, but the initiator of action.

If owner_id is stored only in payload tables, the schema implicitly asserts a false causality: as though process/content exists first, and only afterward is the subject discovered “inside” it.

The correct causal axis runs in the opposite direction:
– the subject initiates an act;
– the act is recorded as a job;
– the payload describes the material/parameters of the act.

In other words:
– job is an event of responsibility;
– payload is the arguments of the event;
– owner_id is an attribute of the act, not an attribute of the material.

Therefore, owner_id must reside in the root entity jobs, not in the “replaceable flesh” of payload structures.

12) Practical Architecture Formula

Recommended form:

Job(owner_id, kind, status, schedule, lease, pipeline_version, dedup_key, ...)

and separately:

JobPayload(job_id, ...)

What this immediately provides:
– a single fast indexed query for “all my jobs” using jobs.owner_id;
– a natural access policy (job.owner_id as the primary predicate);
– clean idempotency within the subject’s boundaries (owner_id + identity key);
– normal retention, cleanup, rate limiting, abuse detection, and audit operations without a zoo of join branches for different payload types.

This is not merely “more convenient storage.” It is the restoration of subjectivity to the beginning of the system’s causal chain.

Subscribe
Scroll to Top