Work-boundaryengineering

Work ownership gets unclear

Teams ship AI-mediated work before naming who owns approvals, exceptions, and post-launch review.

Decisions cross invisible lines

Recommendations, drafts, tool calls, and approvals blur together unless the work boundary is explicit.

Evidence disappears

Human review becomes performative when the workflow does not state what gets tested, logged, or preserved.

Tools become authority

Automation becomes risky when file access, network calls, and retention are broader than the work actually needs.

Delegation design

• Define what AI may do, suggest, execute, or hand back.
• Keep human responsibility visible when work crosses a boundary.
• Design escalation paths for exceptions, risky outputs, and failed checks.

Evidence operations

• Test failure modes before launch.
• Log the evidence needed for review after launch.
• Reconstruct incidents from inputs, tool calls, rules, and missed interventions.

Permission surface

• Restrict file, network, retention, and tool authority to the job.
• Gate dangerous actions instead of relying on optimistic prompts.
• Make tool authority narrow enough to audit.

Why now

AI adoption moved faster than responsibility design. Large-enterprise governance is often too heavy, while small teams still need boundaries, logs, approvals, and tool rules they can operate.

Best-fit teams

• B2B SaaS teams moving from AI features to AI-operated workflows.
• Operators using LLMs internally without clear approval, evidence, or stop rules.
• Small technical organizations that need automation inside security-sensitive work.

Product path

We start as a productized service. We are learning the recurring work patterns of AI-operated teams. The long-term product is the evidence layer for delegated AI work.

What we are not

• Not an AI automation agency.
• Not a generic AI governance program.
• Not only model evaluation.
• Not prompt magic or dashboard theatre.
• Not risk hidden behind optimistic demos.

AI Work Boundary Sprint

For a founder, product lead, or operator preparing one AI-operated workflow for launch.

Deliverables: boundary map, approval matrix, evidence-log template, stop rules, and unresolved-risk list.

• Before: the team knows the AI feature but not the operating boundary.
• After: the team knows what AI may do, what humans own, and what must be logged.
• Risks reduced: unclear ownership, silent overreach, missing review evidence.
• Trust artifacts: boundary map, failure cases, approval rules, evidence checklist.

Delegation Evidence Report

For teams already using LLMs internally or shipping agentic workflow features.

Deliverables: delegation rules, output evidence, failure modes, review criteria, audit-log requirements, and implementation priorities.

• Before: prompts, tools, reviewers, and approvals are mixed inside one workflow.
• After: each decision has an owner, a stop condition, and an evidence requirement.
• Risks reduced: confused-deputy behavior, audit gaps, approval theatre, scope drift.
• Trust artifacts: workflow map, test pack, reviewer policy, launch-risk note.

Agent Permission Surface Review

For teams that need a narrow internal tool or feature surface around AI-operated work.

Deliverables: permission boundary, network/file/data-retention limits, dangerous-action gates, release checklist, and scoped implementation patch when appropriate.

• Before: permissions, files, network calls, and retention are broader than the job.
• After: the tool surface matches the work boundary and fails closed by default.
• Risks reduced: data overexposure, unsafe tool execution, cache leakage, broad enablement.
• Trust artifacts: feature policy, security notes, release checklist, public proof when possible.

AI Incident Reconstruction

For teams that need to explain an AI output incident, bad recommendation, or missed intervention after it happened.

Deliverables: input timeline, referenced context, failed rule, human-intervention point, evidence gaps, and prevention checklist.

• Before: the team has an incident but not a clear account of how it happened.
• After: the team can explain what was seen, what was done, and where the boundary failed.
• Risks reduced: repeated failure, blame ambiguity, unreviewable logs, weak corrective action.
• Trust artifacts: reconstruction report, evidence timeline, missed-stop note, prevention checklist.

VSCode PDF Viewer Secure

Security-first, offline-first PDF viewing for Visual Studio Code. Built for environments that prefer conservative defaults, reduced attack surface, and explicit feature enablement.

Agents Secure Binding

Technical note and link hub for a session-bound Agent identity profile. The profile separates authority grants, holder proof, live session evidence, freshness, and local policy before the application treats a peer as the intended Agent.

dmarc4all

Managed DMARC/SPF/DKIM setup and reporting for teams that want a maintained public service rather than a custom consulting engagement.

Open managed service page

YOLOZU

Framework-agnostic vision model evaluation toolkit centered on a stable predictions.json interface contract for detection, segmentation, keypoints, depth, and 6DoF pose.

Thermo-Credit theory and dashboard

Exploratory economic research on credit dynamics, paired with a public theory note and dashboard. Dashboard readings should be understood as latest available by region, with data gaps treated as visible caveats.

Data freshness: current public report latest dates are JP 2025-03-31, EU 2020-03-31, and US 2025-03-31; checked 2026-06-13.

Kantian and control-theoretic work

Research artifacts remain labeled as research, not service claims. Their role is to show how Toppy reasons about uncertainty, overconfidence, and control boundaries.