Build a KvK contribution report players can check

1. Define what the report measures

Write down the KvK or battle period, its start and end times in UTC, and which cumulative statistics you will compare. Save the baseline before the period starts. A lifetime total alone cannot tell you how much a player contributed during this interval.

For example, 3,890,000,000 ending Kill Points minus a 3,250,000,000 baseline gives 640,000,000 gained KP. The starting and ending values must refer to the same Governor and the same statistic. Keep the source files or screenshots and their capture times so the subtraction can be checked later.

Publish the scoring rule before assessing players. State whether the target uses a fixed amount or a percentage of pre-KvK power, which kills count, how deaths are weighted, and any separate minimums. Custom DKP and in-game Kill Points are different measurements; label them separately in the report.

2. Compare two reproducible snapshots

The following files contain one fictional Governor. Their demonstration identifier, EXAMPLE-01, is an artificial matching key and is not a real Governor ID. For your own roster, use the actual Governor ID to keep identity stable when names change.

Open roster comparison, load the starting file in the before field and the ending file in the after field. The files use these supported headings:

The comparison matches a unique Governor ID first. It can fall back to a unique normalised name when IDs do not conflict, but that is a weaker identity check. Inspect name matches, unmatched rows and duplicates before scoring anyone. Duplicate IDs are not a basis for guessing which row is correct.

Use plain whole numbers in exported CSVs where possible. If you include commas inside an amount, quote that CSV cell so it does not become several columns. Keep unknown figures blank; an explicit zero should mean the value was verified.

3. Apply a custom DKP rule to the gains

For this example only, use weights of 1 per T4 kill, 2 per T5 kill and 4 per dead troop. Enter the period gains from the comparison into the DKP calculator. Entering the ending lifetime totals would credit earlier activity to this period.

Choose a target of 10% of pre-KvK power and enter the 50M starting power. The target is 5M DKP. This player has reached 60%, with 2M DKP remaining. Using the ending 48M power would change the target to 4.8M, which would contradict the published pre-KvK basis.

At these weights, 2M DKP is arithmetically equivalent to 2M more T4 kills, 1M more T5 kills, or 500,000 more dead troops if that category alone supplied the remaining score. These are alternative score equivalents, not instructions to sacrifice troops. Actual battle decisions and eligibility rules require kingdom judgement.

If the policy also requires a minimum number of T4+T5 kills or dead troops, check those separately. The example has 1.5M combined T4+T5 kills and 250,000 dead troops during the period. Reaching a weighted DKP target does not by itself prove that every separate minimum has been met.

4. Make power-band boundaries unambiguous

Use the KvK requirements builder when different starting-power bands have different rules. State which power snapshot assigns the band. If you use pre-KvK power, retain it even when a player’s current power later rises or falls.

Both ends of a finite band are inclusive. Ending the first band at 50M and starting the next at 50M creates an overlap. Ending at 49,999,999 and starting at 50,000,000 gives the example player exactly one band. Cover the whole intended range and keep the final band open-ended.

Publish the weights alongside the bands, plus any minimum kills, minimum deaths or approved exclusions. A statement such as “10% target” is incomplete if readers do not know the score formula or the power snapshot used.

5. Resolve exceptions before interpreting the ranking

A missing endpoint or baseline leaves that change unknown. An unmatched “added” or “removed” row means the comparison did not establish a match across the two files. It does not, on its own, prove migration, inactivity or refusal to contribute.

A negative change in a statistic you expect to be cumulative needs a source check: confirm identity, column mapping, timestamps and the exact game statistic. Do not turn the negative into a positive or silently replace it with zero. Power can legitimately fall; the −2M power change in this example is not itself the DKP score.

If you track Acclaim or Honor separately, keep their definitions and sources separate too. Current Acclaim and Highest Acclaim are different fields. Honor should belong to the same event being reported. Those values are outside the three-input DKP example and the sample roster CSV; preserve them in a suitable record rather than forcing them into an unrelated column.

For an approved exception or correction, retain the original observation and note the reason, date and reviewer alongside the revised report. This gives a player a concrete value to question and avoids making the evidence disappear during an edit.

6. Publish enough context to reproduce the result

A reviewable report should include the period and capture times, stable player identity, starting and ending values, calculated gains, the exact formula, target basis and any unresolved data gaps. Separate an unverified result from a confirmed shortfall.

For the fictional Governor, the conclusion is: “3M DKP against a 5M target, using 1/2/4 weights and 50M pre-KvK power; 60% complete; 2M remaining.” The supporting snapshots explain that conclusion. A current profile card alone would not.

The public tools perform different steps: compare the CSVs, enter the resulting gains into the DKP calculator, and publish your rules from the requirements builder. The walkthrough does not automatically transfer those values between tools or decide penalties, rewards or exceptions.