Web Function SOP

Detailed subordinate SOP — the Web Function page is the definitive hub · Operations Web Function 0.1.0.

Download the complete plugin · Source SHA-256: dc892dc83228eab6f9ac3567a9e16d8ead33c388fd5f329bcea453bac06a980e

Version: 0.1.0 Status: public, portable reference Parent function: Operations Definition of Operations: repeatable excellence

1. Purpose

The Web Function keeps an organization’s declared web properties reachable, trustworthy, measurable, changeable, recoverable, and documented. It replaces memory, chasing, and status narration with declared coverage, automatic observation, bounded action, independent verification, and durable receipts.

The Web Function is a sub-function of Operations because websites are ongoing production systems. Building a page, onboarding an owner, granting CMS access, checking analytics, responding to an outage, and publishing the lesson all belong to one operating loop.

2. The complete agent equation

running agent
= skill
+ runtime
+ job contract
+ trigger or schedule
+ current context and state
+ approved access adapter
+ policy and human approvals
+ lease and idempotency controls
+ verification
+ immutable receipt
+ evaluation and learning loop

A SKILL.md teaches behavior. It does not create a schedule, authenticate to a CMS, preserve state, decide whether a retry is safe, or prove that a production change worked. Keep those components separate so the skill can move between runtimes and the runtime can change without rewriting the SOP.

3. Function contract

Every installation declares:

scope: which properties, environments, and critical paths belong to the function;
services: what the function owns and what it explicitly does not own;
owners: one accountable function owner and one named owner for every open action;
inputs: authoritative rosters, change requests, alerts, access records, and approved content;
outputs: pages, repairs, inventories, alerts, receipts, reports, and public lessons;
controls: permission ceilings, approvals, backup, rollback, leases, and secret handling;
service levels: observation cadence, acknowledgement and restoration targets, and overdue thresholds;
Definition of Done: observable conditions, not a person’s statement that work is finished;
learning obligation: when a new failure changes the SOP, test, monitor, or template;
publication boundary: what is safe to teach publicly and what stays in a private appendix.

If a property is not in the declared roster, it is not covered. If an owner, deadline, or next trigger is missing, the work is not handed off.

4. Service catalog

The Web Function owns nine repeatable services.

Inventory and lifecycle — register, classify, assign, and retire domains, subdomains, environments, repositories, hosting, DNS, and critical paths.
Build and migrate — launch or move a property with redirects, DNS, backups, analytics, forms, consent, and rollback proof.
Maintain — update core, themes, dependencies, and integrations in a tested order with canaries and read-back.
Secure — observe drift, spam, cloaking, rogue access, persistence, exposed credentials, and monitoring blind spots; preserve before repair.
Measure — keep analytics, tags, calls, forms, bookings, and conversion routes working with test receipts.
Publish — move approved content, media, and schema to production without breaking design, URLs, tracking, or accessibility.
Operate access — grant the minimum role for the minimum time through an approved vault and record; review and revoke it.
Respond and recover — classify, contain, repair, restore, monitor, and close incidents against written criteria.
Document and automate — convert recurring work into tested skills, jobs, examples, and public-safe explanations.

Each request is assigned to one primary service. Split requests that mix unrelated outcomes so each child has its own owner and Definition of Done.

5. Component stack

Layer	Question it answers	Portable artifact
Function	Why does this exist and what does it own?	This SOP and function contract
Skill	How should the agent reason and act?	`skills/*/SKILL.md`
Job	What exact run should occur?	`jobs/jobs.json`
Trigger	When and why should it start?	schedule or event binding
Context	What is true now?	context and property records
Access	What can this run read or change?	access manifest and private adapter
Policy	What is automatic and what needs approval?	permission ceiling and approval digest
State	Has this event/window already run, and who owns the surface?	idempotency key, lease, heartbeat
Evidence	What was observed or changed?	immutable run receipt
Evaluation	Did the result satisfy the contract?	tests, controls, independent verification
Learning	What becomes easier next time?	skill/test/SOP update and redacted case study

6. Intake and routing

For every incoming request or alert:

Normalize the target: property ID, environment, URL or surface, requester, and desired result.
Check the authoritative roster. If the target is absent, route to inventory-web-properties before work begins.
Classify the primary service and risk level.
Choose the narrowest skill and job contract that can produce the result.
Compile current context from authoritative sources; do not rely on copied conversation history when a source record exists.
Resolve access by capability reference. Do not paste credential values into the context.
Determine the permission ceiling and required human approval.
Acquire the correct lease or produce a read-only run identity.
Execute, independently verify, and write a receipt.
Route the receipt: close, monitor, escalate, request approval, or open a learning job.

7. State model

Do not force execution, target health, incident lifecycle, and evidence quality into one red/yellow/green label.

Execution state

Target health

PASS | WARN | FAIL | UNKNOWN

Finding classification

Incident lifecycle

Rules:

UNKNOWN means required evidence is missing or inconclusive. It never means clean.
BLOCKED describes the observation path, not the target. Re-probe from an approved independent vantage and leave health UNKNOWN until then.
FAIL requires positive evidence that an invariant was violated.
A positive failure outranks unknowns. Without a positive failure, any required unknown rolls the run to INCOMPLETE, not PASS.
SKIPPED_LOCKED says another run owns the lease. It says nothing about target health.
A retired property may be intentionally unreachable; an active declared production property may not.

SUSPECT requires one plausible hostile signal or uncorroborated evidence. INFECTED requires passing controls plus either independent reproduction from a second permitted vantage or two structurally independent signal families. Several keywords, title differences, and body differences derived from one response remain one signal family.

8. Standard run lifecycle

A. Plan

Resolve the job version, target, desired state, source event or schedule window, and current policy.
Calculate the idempotency key from job version + target ID + event/window ID + desired-state hash.
Check whether an immutable receipt already proves this exact run.
State the expected evidence and Definition of Done before acting.

B. Acquire

Read-only fleet runs acquire one scheduler lease so duplicate sweeps do not collide.
Write jobs acquire a lease on (target, production surface) with a TTL and heartbeat.
If a previous tool wait timed out, verify whether the underlying process or write completed before retrying.

C. Observe or preserve

Run known-good and known-bad controls before trusting an instrument.
Capture before evidence and source hashes.
On suspected compromise, preserve relevant public responses, headers, timestamps, logs, and internal state before remediation changes it.
Record gaps as UNKNOWN; do not infer an internal clean state from a public homepage.

D. Approve

Create an exact plan digest: target, intended diff, capability, backup, rollback, verification, and blast radius.
Obtain the required approval for that digest. Material changes to the plan invalidate the approval.
A public edit, message, schedule change, production mutation, access change, or baseline promotion requires a human decision unless the organization’s policy explicitly grants a narrower standing authorization.

E. Execute

Recheck the precondition immediately before the write.
Apply one bounded, idempotent change.
For fleet work: canary → bounded cohort → fleet. Stop the wave on a failed verification.
Never let a read-only auditor also become an implicit repair bot.

F. Verify

Read the public or internal target back through a path independent of the writer’s success message.
Test the original failure mode, the desired result, critical adjacent paths, human and crawler views when relevant, and monitoring coverage.
A successful command is evidence that a command returned; it is not proof that production is correct.

G. Receipt and route

Write an immutable receipt and checksum.
Record coverage numerator and denominator, unknowns, owner, deadline, and next automatic check.
Update task and incident systems with a concise projection of the receipt.
Open a learning job for any novel failure, false positive, blind spot, repeated manual chase, or material new control.

9. Approval policy

Automatic by default

Anonymous or explicitly authorized read-only checks.
Local parsing, comparison, classification, and report generation.
Candidate baseline capture marked CANDIDATE_NOT_APPROVED.
Private draft preparation.
Bounded retries of idempotent read-only requests.

Explicit approval

Posting a message or comment.
Public documentation changes or uploads.
Creating, changing, enabling, or disabling schedules.
A single-property production write.
Access grants, revocations, and credential rotations.
Promotion of a captured state to APPROVED_KNOWN_GOOD.

Stronger approval and a change window

Fleet-wide writes.
DNS, hosting, firewall, or infrastructure changes.
Destructive cleanup.
Compromise remediation after preservation.
Installation of a new privileged adapter.

A broad instruction to “fix everything” does not approve an exact fleet plan that has not yet been written. Approval binds to the plan digest, target projection, cohorts, change window, and recipient set.

Never

Put secrets in skills, prompts, receipts, examples, tickets, or public articles.
Approve a baseline merely because it was captured from current production.
Close an incident solely because / returns HTTP 200.
Optimize a suspected compromised system before containment and persistence review.
Blindly retry a mutation after a timeout; read the target back first.

10. Job catalog and cadence

The portable job definitions live in jobs/jobs.json. Bind them to the scheduler and timezone at installation time.

Job	Trigger	Purpose
`web-fleet-daily`	Daily schedule	Canary-gated read-only observation of every declared property.
`web-monitor-alert`	`monitor.alert`	Classify, assign, and open a separate preservation event when needed.
`web-incident-preserve`	`incident.opened` with suspected compromise	Capture volatile evidence before anyone repairs.
`web-incident-repair`	`incident.repair_approved`	Apply one evidence-backed, approved repair and verify or roll back.
`web-approved-change`	`change.approved`	Apply one approved change to one property.
`web-fleet-approved-change`	`fleet-change.approved`	Run an approved canary and bounded cohorts, halting on unknown or failure.
`web-incident-communication`	`incident.communication_approved`	Send one approved factual update; resolution requires a verification receipt.
`web-deploy-verify`	`deploy.completed`	Independently read back the changed surface and critical paths.
`web-property-onboard`	`property.added`	Add inventory, ownership, critical paths, analytics, access, and monitoring.
`web-property-retire`	`property.retired`	Archive, redirect, revoke, and remove intentionally from active coverage.
`web-weekly-maa`	Weekly schedule	Metrics → Analysis → Action for coverage, unknowns, incidents, and overdue receipts.
`web-monthly-controls`	Monthly schedule	Restore test, access review, inventory freshness, and planted-change test.
`web-quarterly-reconcile`	Quarterly schedule	Reconcile ownership, lifecycle, DNS, hosting, repos, access, and retired properties.
`web-resolved-learn-publish`	`incident.resolved` or `runbook.changed`	Convert evidence into tests, SOP updates, and a redacted public example.

11. Monitoring contract

A daily external sweep should, at minimum:

state checked / declared coverage;
prove the instrument using a known-good control and a deliberately invalid path;
check critical paths, not just the homepage;
compare a normal browser identity with a real crawler identity;
use an impossible-path canary that must remain absent;
separate DNS, TLS, connection, WAF/bot blocking, HTTP error, content drift, and compromise signals;
compare external resources only against a human-approved known-good baseline;
preserve UNKNOWN for users, plugins, must-use plugins, files, database, cron, and host state unless an authenticated collector actually checked them;
hash the roster, code, policy, and context used for the run;
write one immutable receipt plus an optional latest pointer;
automatically open the matching event job when a threshold is crossed.

A green homepage cannot prove a clean filesystem. A clean sitemap cannot prove the absence of injected URLs. A timeout proves the observation failed to complete, not that the site is down.

12. Incident Definition of Done

An incident may move to RESOLVED only when:

the affected surface returns the intended result from the required vantage points;
the original failure was reproduced or its evidence was preserved;
the cause and correction are stated separately;
persistence and reinjection paths were identified or explicitly remain UNKNOWN;
required authenticated layers have dated receipts or clearly assigned gaps;
exposed credentials were rotated and moved to the approved vault;
the fix was independently read back;
monitoring catches the original class of failure;
the root-cause/root-correction record is linked;
a sustained monitoring window has passed when recurrence is plausible.

CLOSED additionally requires that no unowned follow-up, overdue control, or unresolved public/client communication remains.

For recurrence-prone incidents, the incident record declares a stability-window duration and required number of automatic checks. The organization sets these values in policy. RESOLVED is unavailable until both the duration and check count pass; do not invent a shorter window during triage.

13. Production-change Definition of Done

A production change is complete only when the receipt contains:

exact target and intended diff;
approved plan digest and approver;
before fingerprint and backup or rollback reference;
precondition recheck;
action performed by an identified actor or adapter;
independent after-read of the changed surface;
verification of critical adjacent paths, analytics, forms, redirects, and crawler view when relevant;
rollback result if verification failed;
next automatic check and owner;
public-safe summary and private appendix reference.

14. Access contract

Inventory capabilities, not passwords: cms.read, cms.publish, host.logs.read, dns.write, and similar scopes.
Context files contain a vault or connector reference, never the credential value.
Grant the smallest role, property scope, and duration that can finish the job.
Separate read-only observation from write access.
Record requester, approver, principal, scope, grant time, expiry, review date, and revocation receipt.
Reconcile access when a property or person leaves the function.
A missing or stale credential is an Operations finding, not a reason to paste a replacement into a ticket.

15. Evidence tiers

Assign evidence quality to each claim, not merely to the report.

Tier	Meaning
`E0`	Assertion or progress narration; no reproducible proof.
`E1`	One timestamped external observation.
`E2`	Reproducible multi-identity or multi-vantage observation with exact inputs and tool hashes.
`E3`	Authenticated read-only internal corroboration: users, dependencies, files, logs, jobs, or host state.
`E4`	Approved change with before state, exact diff, rollback, and independent after-read.
`E5`	Sustained monitoring-window proof plus a negative/control test or independent third-party confirmation.

The evidence ledger records what has actually been demonstrated. It does not award a superlative because the publisher wrote one.

16. Standard receipt

Each immutable receipt includes:

schema/version, run ID, parent/correlation ID;
job version, trigger, target, policy version, and skill/source hashes;
context sources and input hashes;
actor/principal and capability used, never secret values;
approval identity and plan digest when a write is involved;
timestamps and coverage numerator/denominator;
before evidence, bounded action, and after verification;
execution state, target health, classification, and evidence tier;
unknowns, errors, retry decision, next check, owner, and due time;
public/private classification and redaction record;
checksum.

The action ledger is a generated human-readable projection of receipts. It is not a substitute for them.

17. Metrics → Analysis → Action

Track:

declared properties and critical paths;
monitored / declared coverage;
controls executed / controls required;
alerts, failures, and unknowns by age;
mean time to detect, acknowledge, contain, restore, and close;
repeat-incident rate;
changes independently verified / changes made;
novel incidents that changed a skill, test, monitor, or runbook;
restore tests passed / attempted;
access grants overdue for review or revocation;
credentials found outside the vault;
tasks overdue without a receipt;
public examples and releases updated within the declared freshness window;
independent reproductions and citations, when available.

Every review ends with named actions, due dates, and the trigger that will check them. A chart without an action is observation, not Operations.

18. Learning and publication loop

For each novel incident or meaningful run:

Establish the facts from receipts and source records.
Resolve the exact Task Library row, exact task page, broader definitive article, executable skill source, and prior accepted meta examples.
Write the instance as a meta article, including decisions, deviations, guesses, elapsed time, evidence, outcome, and unknowns.
QA the run against the definitive article; give each flag one source correction.
Separate root cause from root correction.
Fix the narrowest authoritative source in the same run where possible.
Make the contradiction or regression automatically detectable.
Prove the new check can fail against a planted or historical fixture.
Run the changed path again.
Propose the skill/job/source change through branch, checks, review, and human merge; never hot-edit a downstream mirror as the durable fix.
Redact credentials, customer data, private infrastructure, and exploitable detail.
Regenerate the task/implementation page, definitive hub when changed, evidence tier, limitations, and downloadable artifact from their owned sources.
Run a fresh-chat activation canary, then observe the next scheduled/event firing.
Link receipt → meta article → source correction → test → release from the evidence ledger and originating task.

Generate public skill pages from the source skill files when practical. A hand-edited page beside a changing skill will drift.

The master is one registry graph with artifact-level owners: bounded tasks in the reviewed Task Library, reusable high-level skills in the merged marketplace, and generated pages/archives as projections. Exact task pages, broader definitive articles, skills, and meta examples remain distinct linked artifacts. See docs/MASTER-SOURCE-AND-LEARNING-LOOP.md and registry/capability-map.json. The Web Function delegates to existing owners instead of forking them; every new task or interface remains a candidate until reviewed, registered or merged, fresh-chat tested, and propagated.

19. Public and private boundary

Public	Private
Function architecture; job and check definitions; source code without secrets; fictional configs; redacted timelines; coverage counts; tool and release hashes; lessons; limitations	Passwords and tokens; account and admin lists; private host paths and IPs; raw logs with personal data; private client rosters; exploit payloads; unpatched persistence details; vault identifiers that reveal access structure

When a public explanation depends on a private fact, publish the conclusion, evidence tier, and verification method—not the secret or attack recipe.

20. Adoption sequence

Declare the roster and freshness rule.
Run the read-only monitor manually with controls.
Schedule the daily observation job.
Connect alert routing and require a receipt for closure.
Add authenticated read-only collectors.
Add deployment verification triggers.
Add access governance.
Add approved single-property writers.
Prove canary, lease, rollback, and independent verification before any fleet writer.
Publish redacted examples and update the evidence ledger continuously.

The first milestone is not “full autonomy.” It is complete coverage with honest unknowns and no silent failure. Autonomy expands only as the evidence and controls support it.

This page is generated from docs/WEB-FUNCTION-SOP.md. Do not hand-edit the public copy.