net-kingdom/canon/standards/posture-feedback_v0.1.md

---
id: netkingdom-posture-feedback-v0.1
type: standard
title: "NetKingdom Posture Feedback v0.1"
domain: netkingdom
status: proposed
version: "0.1"
owner: net-kingdom
created: "2026-08-23"
updated: "2026-08-23"
last_reviewed: "2026-08-23"
review_interval: 3m
scope: self-optimizing-security
schema:
  - canon/schemas/posture-feedback-report_v0.1.schema.json
validator:
  - tools/posture-feedback/posture_feedback.py
related:
  - canon/standards/tenancy-posture_v0.1.md
  - canon/standards/security-zones_v0.1.md
---

# NetKingdom Posture Feedback v0.1

## 1. Purpose

This contract is the first bounded C6 feedback mechanism. It turns explicit
posture review dates, evidence freshness, implemented-but-unevidenced controls,
and declared gaps into deterministic remediation **proposals**.

It does not modify a posture level, policy, declaration, workplan, State Hub,
or runtime. Human or separately governed automation decides whether a proposal
becomes work.

## 2. Deterministic time

Evaluation requires an explicit RFC 3339 `as_of` timestamp. Wall-clock time is
never read implicitly. A date-only `review_due` remains current through that
calendar date in UTC and becomes overdue on the following UTC date.

A non-negative horizon in days identifies items due soon. Changing the horizon
changes the report digest and is therefore visible.

## 3. Owner resolution

The evaluator routes only from authoritative declaration fields:

- posture review, gaps, and implemented controls: `responsible_repo`;
- evidence replacement: `evidence_freshness.<level>.responsible_repo`;
- security-zone review: `zones.responsible_party`.
- execution findings (§4a): `responsible_repo` for the receipt's `executing_workload` in
  `tools/posture-feedback/execution-owners.yaml`.

If the relevant field is absent, owner resolution is `unknown`. The evaluator
must not infer ownership from the service name, repository path, Git remote,
previous work, or another policy subject.

## 4. Finding classes

| Finding | Trigger | Severity |
| --- | --- | --- |
| `posture-review-overdue` | `as_of` is after `tenancy.review_due` | high |
| `posture-review-due-soon` | review is within the horizon | medium |
| `zone-review-overdue` | `as_of` is after `zones.review_due` | high |
| `zone-review-due-soon` | zone review is within the horizon | medium |
| `evidence-freshness-unknown` | a current adversarial level has no complete freshness entry | high |
| `evidence-expired` | `as_of` is after `valid_until` | high |
| `evidence-due-soon` | evidence expires within the horizon | medium |
| `implemented-not-evidenced` | an `implemented` level is above `current` | medium |
| `declared-gap` | a non-empty `tenancy.gap` entry exists | low |

The review horizon does not generate a due-soon finding for an item already
overdue or expired. Exact equality with a timestamp is still valid; expiry is
strictly `as_of > valid_until`.

Current adversarial levels are `E2`, `R4`, and `V2`–`V4`. This vocabulary comes
from Tenancy Posture §13. Mechanical evidence is evaluated for expiry only when
its declaration explicitly supplies `valid_until`.

## 4a. Execution findings (added 2026-11-04, NK-WP-0056-T07)

With `--receipts`, the evaluator also reads bounded-executor events: `execution.run.started` and
`execution.attribution.receipt`. Each event must pass the Execution Attribution Receipt v0.1 validator
(`tools/execution-attribution-receipt/`). An invalid event, or a started/receipt pair that does not match (EAR-10),
is a validation error, never a finding. Runs are joined by `run_id`. A finding's control is
`admission:<id>#run:<run_id>`.

| Finding | Trigger | Severity |
| --- | --- | --- |
| `execution-receipt-missing` | a started event with no receipt among the inputs | high |
| `execution-not-completed` | outcome `unknown`, `revert_failed`, `stopped` or `budget` | high |
| `execution-reverted` | outcome `reverted` | medium |
| `execution-budget-pressure` | wall time used is at least 80 % of the admitted limit, or more than one attempt | low |
| `execution-recurring-revert` | two or more reverted admissions for the same executor and consumer set | high |

`execution-recurring-revert` is the aggregate review of recurring admissions. Its control is
`consumers:<sorted consumers>` and its reason lists the admissions. The evaluator reads no wall clock here
either. Receipts carry their own times, and the report's `as_of` stays explicit.

## 5. Proposal and safety boundary

Every finding receives a stable id derived from its source declaration,
service, finding class, control, and due value. It contains the authoritative
owner or `unknown`, current evidence state, reason, and recommended action.
For declarations under the workspace containing this repository, the source is
normalized to `<repo>/<path>` so absolute checkout locations do not perturb the
identity. This source normalization identifies an input only; it is never an
ownership inference.

Every report declares:

```yaml
automation:
  mode: proposal-only
  external_write_permitted: false
  policy_mutation_permitted: false
  declaration_mutation_permitted: false
```

Expired or unknown evidence does not silently inherit freshness and does not
silently downgrade a level. It makes the uncertainty visible for governed
review. Consumers that use the report as an admission gate may fail closed on
high findings, but that is a separate owner decision.

## 6. Exit behavior

The CLI emits a report conforming to
`posture-feedback-report_v0.1.schema.json`. `--fail-on high` exits non-zero when
at least one high-severity finding exists; `medium` includes medium and high;
`low` includes every finding; `none` reports without a finding-based failure.
Invalid declarations always exit non-zero.