Build · Assess & Decide · Writing & Content
Build a Performance-Overshoot and Basis-of-Competition Register
A structured overshoot register: one row per market tier recording demanded vs delivered performance, an overshoot verdict, and the predicted next basis of competition, computed by rule from the numbers the buyer supplies.
You receive: A JSON object with a metric definition and a tiers[] array, each tier carrying a computed overshoot flag and a next_basis enum.
Part of Choose Business Model
What's verified: STUD verifies each tier's overshoot flag is arithmetically derived from the demanded/delivered numbers, the basis-of-competition transition follows the overshoot state, and the rows are consistent and ordered. It does NOT judge whether the buyer's performance numbers are accurate or whether disruption will actually occur; it enforces the model's internal logic, not real-world measurement.
Opens soon
This objective is verified and ready. It opens soon, once sign-in and payments are live.
Deliverable interface
The exact vocabulary the automated check enforces: keys, tokens, entry points, and worked examples. Generated from the verification source.
{
"buyerParamKeys": [
"performance_metric"
],
"checkNames": [
"format_parses",
"metric_defined",
"tiers_min_count",
"tier_shape_valid",
"overshoot_computed_correctly",
"next_basis_consistent",
"wtp_indifferent_requires_overshoot",
"tiers_sorted_ascending"
],
"constants": {},
"deliverableLabel": "overshoot_basis_register",
"documentKeys": [
"delivered_performance",
"demanded_performance",
"next_basis",
"overshoot",
"performance_metric",
"tier_name",
"tiers",
"unit",
"willingness_to_pay_for_more"
],
"enumLiterals": [
[
"high",
"indifferent"
],
[
"performance",
"reliability"
],
[
"performance",
"reliability",
"convenience",
"price-customization"
]
],
"submission": "a JSON document (submitted as a string), validated as data; every check below must pass",
"tier": "doc-validator"
}Get early access to STUD the day it goes live.