Scope Statement
This set targets weak-tie online collaborations, cross-disciplinary teams, and high-uncertainty projects that need an engineering contract to enable parallel work and enforce stop-loss behavior.
It reduces communication overhead, shifts risk management earlier, and keeps execution traceable.
Non-Applicable Scenarios
Not for social chat, personal relationships, or contexts outside engineering delivery; no enforcement or judgment occurs there.
Non-Bias Principle
Decisions rely solely on engineer-verifiable artifacts (deliverables, interface contracts, acceptance definitions, versioned changes, explicit timelines).
Transparency & Misunderstanding Prevention
This is an explicit pre-collaboration contract. Expectations, boundaries, and default actions are shared before work begins to avoid escalations.
Purpose: filter collaborators at minimal cost, enable parallel work, and cut losses when risk becomes significant.
Principles: judge only by verifiable deliverables; avoid motive debates; drive progress with time windows.
0. Scope and Objectives
0.1 Scope
- Weak-tie online collaboration across chats/schools/domains.
- Software-hardware or high-uncertainty projects (competitions, coursework, prototypes).
0.2 Engineering Objectives
- Low-cost screening: turn “interest” into artifact commitments.
- Parallel collaboration: contract-first, versioned interfaces plus acceptance criteria.
- Fast stop-loss: default actions end investment before sunk cost.
1. System Model
The collaboration state machine advances only when artifacts satisfy specs, never based on narratives.
| State | Name | Definition | Allowed Discussion | Exit Conditions |
|---|
| S0 | Probing | Idea exchange only; no commitment | Context/value/rough direction | Send onboarding request → S1 |
| S1 | Entry Evaluation | Request MIP/MVW with deadline | Materials and deliveries only | Pass → S2; overdue → S4 |
| S2 | Kickoff | Contract/interface/acceptance and parallel work start | Artifact-driven execution | Red flags trigger → S3 |
| S3 | Risk Watch | Red flags observed; remediation timeboxed | Remediation checklist only | Remediate → S2; overdue → S4 |
| S4 | Stop-Loss Freeze | Project discussion stops | Optional non-work relationship | Artifact-based re-eval → S1 |
States change only when artifacts exist and meet specs—not based on attitudes.
2. Terms & Artifact System
Defines minimum inputs (MIP) and verifiable work (MVW).
MIP requires stack declaration, interface draft, variables, acceptance definition, risks/unknowns.
MVW must deliver within 48h any one artifact: interface contract, validation plan, or prototype evidence.
3. Onboarding Protocol
Entry gates:
- You declare role and boundaries.
- Other party initiates or owns accountability.
- Agreement to use documents/artifacts, not verbal-only.
Request template:
Provide by T+48h: 1) MIP-A/B placeholder; 2) Any MVW (contract/plans/prototype).
Default action: if unmet, assume project execution state is invalid and halt investment.
Deadline rules: Within 48h deliver stack/transport/interface + MVW; longer cycles still need placeholders.
Placeholder spec: Must show hardware model/transport, data direction + payload skeleton, and promised updates.
5. Red Flags & Triggers
- R1: Discussion replaces delivery.
- R2: Responsibility inversion excuses.
- R3: Labeling instead of answering artifact questions.
- R4: Drift without updating docs.
- R5: Unequal terms with unclear returns.
Two red flags → S3 remediation notice (48h).
Remediation: complete MIP-B fields + MIP-D acceptance with reproduction steps by T+48h or freeze conversation.
6. Stop-Loss Freeze (S4)
Freeze when: repeated artifact dodge, deadline miss, responsibility inversion.
I understand your perspective, but I won't continue participating in this project or discuss content further.
After freeze, no re-entry except through artifact-based re-evaluation.