How Our Web Function Works

The Web Function inside one system

The Web Function is the website sub-function of Operations. We define Operations as repeatable excellence: a result can be produced repeatedly, at a declared quality level, with visible ownership and evidence, without depending on one person’s memory or availability.

The System is the public master map. Nine Triangles supplies the Marketing, Operations, and Finance operating model. Content, Web, Finance, training, and agent infrastructure are related parts of that framework—not separate empires with competing SOPs.

Billing belongs under Finance, but its exact bounded-task owner is not yet registered. We show that gap instead of quietly making the Web Function own it. Training uses the same definitive-article, Task Library, and meta-article loop; agent infrastructure uses the existing agent, skill-pack, persistent-job, and receipt layers.

One master, not five silos

Four linked artifacts do different jobs:

1. the exact Task Library page defines one bounded outcome;
2. the broader definitive article owns the concept;
3. the agent-readable skill or interface explains how to act;
4. a structured meta example records what happened in a real run and what the source learned.

High-level reusable skills are owned by reviewed sources in dennisyu/blitzmetrics-skills; bounded task contracts are owned by reviewed rows in Goodrich-Dev/task-library; generated pages, ZIPs, installs, schedules, and mirrors are projections with receipts. An orchestrator routes work; it is not counted as another task or another method.

This release originally risked competing with security-audit, client-access-checklist, weekly-brand-maa, recursive-self-improvement-qa, definitive-article-writer, and skill-registry. Overlap QA corrected that before publication. Only property inventory, web-incident triage, and incident-evidence preservation remain proposed new bounded tasks; the other Web artifacts are explicit delegates or control interfaces.

This follows the BlitzMetrics guides for documenting a task, definitive articles, and the meta-article self-improvement loop.

How work moves through the Web Function

Every request has one primary service, target, owner, due time, permission ceiling, and observable Definition of Done. A mixed request is split before execution. The receipt closes the run; a novel lesson can then improve the task, definitive article, canonical skill, and test through review.

Canonical owners: one method each

The downloadable Web pages labeled “candidate” are not claims that those skills have merged into the marketplace. Until a reviewed merge and activation receipt exist, they remain candidate task gaps, thin delegates, or supporting interfaces.

A skill file is not the whole agent

running agent
= skill + runtime + job + trigger + current context/state
+ access adapter + policy/approvals + lease/idempotency
+ independent verification + immutable receipt + learning loop

A skill teaches behavior. It does not create a schedule, authenticate to WordPress, preserve state, decide whether a retry is safe, or prove a live change worked. Keeping those components separate lets another company reuse the Web Function with its own scheduler, CMS, host, vault, and task system.

The portable component model is:

1. Function contract — purpose, scope, owner, service level, and Definition of Done.
2. Skills and exact tasks — the canonical methods an agent invokes.
3. Jobs and triggers — the bounded run, cadence or event, permission ceiling, and halt conditions.
4. Context and access adapters — current property state and least-privilege bindings.
5. Controls — approvals, leases, idempotency, canaries, backup, rollback, and retry policy.
6. Verification and receipts — independent read-back and immutable evidence.
7. Learning and publication — public-safe examples and reviewed source improvements.

Jobs and triggers

• Daily: canary-gated external observation of every active declared property.
• On monitor.alert: triage, preserve when necessary, assign, and set the next check.
• On deploy.completed: independently verify the public and critical paths.
• On property.added or property.retired: reconcile inventory, access, monitoring, redirects, and lifecycle.
• Weekly: contribute Web metrics, analysis, and actions to the canonical MAA.
• Monthly: run restore, access, roster-freshness, and planted-change control tests.
• Quarterly: reconcile ownership, DNS, hosting, repositories, analytics, and access.
• On incident.resolved: correct the authoritative source, add a regression test, redact, and publish the lesson.

Only the anonymous daily observer is bound end to end in version 0.1.0. The other entries are portable contracts until an adopter supplies its runtime, owner, adapters, policy, and first-fire receipt. A job definition is not proof that a scheduler registered or ran it.

Built in public and taught in practice

The system comes from work done with real teams, on real sites, and in live training—not from inventing a diagram after the fact. We publish the reusable method and public-safe receipts so clients, builders, and other operators can inspect it, run it, criticize it, and improve it.

State, evidence, and production boundaries

Execution state, target health, finding classification, incident lifecycle, and evidence quality are separate.

• UNKNOWN means evidence is missing. It never means clean.
• BLOCKED describes the observation path, not the site.
• A timeout describes the observer, not the target or background process.
• A successful write response does not prove production is correct.
• A public external pass does not establish that users, plugins, files, database, scheduled tasks, or host state are clean.

Evidence tiers run from E0 narration to E5 sustained proof with a negative/control test or independent confirmation. Each claim gets its own tier.

Read-only observation and local analysis can run automatically. Messages, public edits, schedule changes, access changes, and production writes follow the declared approval policy. Fleet writes require a canary, bounded cohorts, an active write lease, halt conditions, rollback, and independent verification.

Never put passwords, tokens, account lists, private host details, customer data, raw forensic payloads, or unpatched exploit details in a skill, prompt, ticket, example, receipt, or public article.

Field evidence, not a self-awarded superlative

We want this to become the strongest public reference for operational marketing agents. We earn that position through evidence others can compare:

• A fleet sweep with a real denominator checked 221 of 221 selected domains and recorded source hashes plus aggregate states without claiming authenticated layers were clean.
• A monitor learned to stop crying wolf by converting a false positive into structural parsing and positive/negative regression fixtures.
• UNKNOWN is not clean shows why failed probes must remain visible instead of quietly appearing green.
• A skill in a ZIP is not yet citable separates a delivered artifact from a public, provenance-bearing implementation page.
• Stopping a second master before publication records the overlap correction that changed owners, dependencies, receipts, tests, generated pages, and the release hash.

These are candidate meta examples, not accepted Task Library historical examples. Independent reproductions and citations remain open evidence gaps until they exist.

Download and adopt the Web Function

Download Operations Web Function 0.1.0 SHA-256: 39e3e04bdeb00350645da8b7bc1293cded404c59a035c2df1fc3938d151b78e5

The package contains candidate task/interface files, job contracts, schemas, a credential-free observer, fictional examples, tests, generated implementation/reference pages, and public-safe evidence. Downloading it does not install canonical dependencies, register a Task Library task, create a schedule, or grant production access.

1. Download and unzip the package.
2. Resolve the declared canonical skills and exact Task Library dependencies; do not copy them into another fork.
3. Move the fictional context and property examples to a private working location.
4. Bind your own roster, timezone, owners, connector references, approval policy, receipt store, and secret references.
5. Run the validator, monitor self-test, and tests.
6. Prove a small manual read-only observation.
7. Register only a job whose SLA is not already owned, read the scheduler definition back, and capture its first immutable receipt.
8. Add authenticated reads, alert routing, deploy verification, access governance, and approved writers in that order.
9. Publish redacted receipts, corrections, and structured examples at stable URLs.

Read the subordinate detailed SOP, master registry and learning contract, and public evidence and limitations ledger.

Current reconciliation work

Publishing a page or a package does not erase contradictions in the working system. Open work includes choosing one canonical fleet-monitor skill and engine, consolidating overlapping full-fleet schedules, building one property registry with purpose-specific projections, reconciling the approved vault and provisioning policy, splitting incident history from current state, registering the three proposed bounded tasks, and capturing separate installed, enabled, scheduled, and observed receipts.

The marketplace and Task Library continue to move after a versioned release. This page treats the downloadable 0.1.0 package as a pinned candidate snapshot, not as the current marketplace master.

Updated August 13, 2026. Package version 0.1.0.