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

id	type	title	domain	status	version	owner	created	updated	last_reviewed	review_interval	scope	schema	validator	related
netkingdom-posture-feedback-v0.1	standard	NetKingdom Posture Feedback v0.1	netkingdom	proposed	0.1	net-kingdom	2026-08-23	2026-08-23	2026-08-23	3m	self-optimizing-security	canon/schemas/posture-feedback-report_v0.1.schema.json	tools/posture-feedback/posture_feedback.py	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:

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.