← Operations Web Function

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.

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

6. Intake and routing

For every incoming request or alert:

1. Normalize the target: property ID, environment, URL or surface, requester, and desired result.
2. Check the authoritative roster. If the target is absent, route to inventory-web-properties before work begins.
3. Classify the primary service and risk level.
4. Choose the narrowest skill and job contract that can produce the result.
5. Compile current context from authoritative sources; do not rely on copied conversation history when a source record exists.
6. Resolve access by capability reference. Do not paste credential values into the context.
7. Determine the permission ceiling and required human approval.
8. Acquire the correct lease or produce a read-only run identity.
9. Execute, independently verify, and write a receipt.
10. 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

QUEUED | RUNNING | WAITING_APPROVAL | COMPLETE | PARTIAL | FAILED | SKIPPED_LOCKED

Target health

PASS | WARN | FAIL | UNKNOWN

Finding classification

OK | DEGRADED | DOWN | SUSPECT | INFECTED | BLOCKED | UNREACHABLE

Incident lifecycle

OPEN | CONTAINED | REPAIRING | MONITORING | RESOLVED | CLOSED

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.

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.

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:

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

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

1. Declare the roster and freshness rule.
2. Run the read-only monitor manually with controls.
3. Schedule the daily observation job.
4. Connect alert routing and require a receipt for closure.
5. Add authenticated read-only collectors.
6. Add deployment verification triggers.
7. Add access governance.
8. Add approved single-property writers.
9. Prove canary, lease, rollback, and independent verification before any fleet writer.
10. 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.