Core concepts

A short tour of the model. Once these click, the rest of the product is intuitive.

Tenancy: organizations & projects

• Organization — your tenant. Every row of data carries a tenant id and is isolated by PostgreSQL row-level security. Nothing leaks across orgs.
• Project — a workspace inside an org that groups catalog, releases and policies. Most work happens in a project.

Catalog: products, services, environments

• Service — the unit a release is scoped to; identified for attribution by its repository URL. A service has a kind: service, component (library) or resource (database/queue).
• Product — a grouping of services for rollup views.
• Environment — a deploy target (staging, production, …), optionally requiring approval.
• Relationship — a typed edge between services (calls, depends_on, publishes_to) that powers the dependency graph and lineage.

Evidence

Evidence is a typed, canonical event ingested from a connector — for example scm.pr.merged, tracker.issue.updated, build.completed, artifact.published, deployment.completed, infra.plan.applied. Raw payloads are archived; normalized events are what the engine reasons over. See the event taxonomy.

Release

A release is a record for a version of a service (or a train). It carries a version, type, git tag/branch, an optional baseline (what to compare against), and — after reconciliation — its confidence, counts and classified evidence. Releases move through a state machine:

draft → reconciling → ready | ready_with_exceptions | blocked_by_policy
      → approved → published
      (+ approval_suspended, superseded, rolled_back)

Reconciliation

Reconciliation is the engine run that turns raw evidence into release truth. Its stages:

1. Scope resolution — determine the release window (baseline → tag/now).
2. Evidence collection — gather events in the window for the service.
3. Clock-skew normalization — tolerate cross-system timestamp drift.
4. Deterministic attribution — attach evidence by service id, repo URL, issue-key linkage.
5. Heuristic attribution — branch-name / path / commit-text heuristics when deterministic signals are absent (each tagged with its rule).
6. Classification — label each item.
7. Backport detection — flag changes carried from earlier releases.
8. Force-push handling — invalidate rewritten commits.
9. Confidence scoring — weighted score from the evidence profile.
10. Policy evaluation — apply the project’s gates.
11. Snapshot write — persist the result (frozen at publish).

Classification

Every evidence item ends up in one class:

Class	Meaning
included	Deterministically attributed and in scope.
included_heuristic	Attributed by a heuristic rule (rule recorded).
excluded	Attributed to a different service / out of scope.
uncertain	Couldn’t be confidently placed — needs review.
orphaned	An unattributed merged change — a real signal, surfaced not hidden.

Confidence score & tier

A confidence score (0–1) grades how well-supported the release truth is, from weighted components: tag anchor, all-PRs-linked, artifact present, deployment present, no orphans, no force-push, builds green — minus deductions (missing artifact/deployment, orphans, force-push, high heuristic ratio, rollback). It maps to a tier: high ≥ 0.8, medium ≥ 0.6, else low. See the Confidence guide.

Exceptions

Orphans, uncertain items, force-pushes and rollbacks are collected as exceptions — the things a human should look at. Policy gates can block a publish on them.

Governance

• Policy — per-project gates (min confidence, required approvals, orphan/heuristic limits).
• Approval — an N-of-M sign-off with a decision history; self-approval is banned.
• Freeze window — a period during which publishing is blocked (an approved sign-off can act as a waiver).

Evidence-backed, always

Every score, classification and note traces back to stored evidence, and publishing freezes an immutable snapshot. That’s what makes Reloqui’s answers auditable rather than merely plausible.