PROJECT CONSISTENCY REPORT

Project: ASTRA: KALYUG PROTOCOL Date: 2026-08-01 Author: Technical Director (Claude / Opus 5) Status: AWAITING APPROVAL — no changes made, no code written Scope of audit: the four supplied documents, in full, plus the ProjectOS brief and the existing Aurion infrastructure they must live on.

0. Headline finding (read this first)

The four project documents total 1,250 bytes / 87 lines:

Document	Bytes	Lines
01_ASTRA_Project_Bible.md	521	25
02_ASTRA_Game_Design_Document.md	305	22
03_ASTRA_Technical_Architecture.md	245	19
04_ASTRA_Production_Bible.md	179	21
Total	1,250	87

These are index cards, not bibles. They are a valid and useful statement of intent — the hard rules in particular are unusually disciplined and I would not change them. But they do not yet specify a game.

This matters more than any individual contradiction below, because of a dependency you have not yet seen:

ProjectOS cannot be built on top of these documents as they stand.

ProjectOS is specified as "the single source of truth" with an Asset Manager tracking polygon budgets, a Consistency Engine checking broken references, and a Dashboard showing "Completion %". Every one of those modules needs an input that does not exist:

Asset Manager needs a global performance budget to allocate from → none exists.
Consistency Engine needs a machine-readable ID/reference format → none exists.
Dashboard needs milestone exit criteria and task estimates → none exist.
Map Builder needs 10 named zones → the GDD says "10 Combat Zones" and names zero.
Character Manager needs abilities and cooldowns → five hero names exist, zero abilities.

So the honest sequencing is: ProjectOS can be built as a shell with real schema and empty tables, and it will look impressive and be genuinely useful as a container — but it will display "0%" everywhere until the design documents are written. I can build that shell. You should know that is what it is.

The alternative reading — "build ProjectOS first so that the documents get written inside it" — is legitimate and probably correct. It just needs saying out loud, because it changes what "done" means for the first deliverable.

1. Direct contradictions

These are cases where two documents (or a document and the ProjectOS brief) cannot both be true.

C-01 — CRITICAL — Monetization rules vs. progression systems

Bible #6: "Never Sell Competitive Advantage"
Bible #7: "Cosmetics Only"
GDD: "Relics", "3 Rune Slots", "Karma", "Progression"

Relics, runes, karma and progression are, by default reading, power systems. Nothing in any document states whether they are:

(a) in-match only — looted each match, reset on death, zero meta carry-over → compatible with #6/#7, or
(b) account-persistent — unlocked/levelled between matches → breaks #6 and #7 outright, and breaks #11 ("Gun skill wins") as a side effect.

This is the single most load-bearing undefined decision in the project. It determines the entire economy, the entire backend, and whether the game is a fair BR or a power-progression BR. It cannot be deferred, because the Asset Manager, the Weapon Manager and the backend schema all branch on it.

Recommendation: declare (a) in-match only for relics and runes, and define Karma as a behavioural/reputation system with zero combat effect. Put progression entirely in cosmetics, titles, and account level with no stat attached. This is the only reading consistent with all eleven hard rules. If you want (b), then rules #6, #7 and #11 must be formally amended and the amendment recorded — do not let it happen by drift.

C-02 — CRITICAL — "Gun skill wins" vs. five ability-based heroes

Bible #5: "Identity over Power"
Bible #11: "Gun skill wins"
GDD: Hanuman, Ravana, Sita, Krishna, Arjuna
ProjectOS brief: Character Manager tracks "Abilities, Cooldowns"

Hero abilities are, by definition, power. If Hanuman can leap and Arjuna has a guided arrow, then gun skill does not unilaterally win — the ability contributes. The Bible asserts both, with no reconciliation.

This is not fatal; it is normal for a hero-BR. But it is unresolved, and unresolved means it will be resolved 200 times inconsistently by 200 future balance decisions.

Recommendation: adopt an explicit Ability Impact Budget as a hard rule, e.g. "No ability may deal more than X% of a target's max HP, and no ability may secure a kill without a follow-up weapon shot." That makes #11 enforceable and testable instead of aspirational. Abilities then serve #5 (identity) — mobility, information, repositioning, denial — not damage.

C-03 — CRITICAL — "Prana combat" is a pillar with no system behind it

Bible → Pillars: "Prana combat"
GDD → Systems: no Prana. Anywhere.

Prana is listed as one of five project pillars — i.e. a differentiator — and then never appears again in any document. Either:

the GDD is missing the project's single most distinctive mechanic, or
the pillar is stale and should be deleted.

This is the most important dangling reference in the project. "Mythology-first BR" without Prana is just a BR with Indian skins, which is a much weaker market position and a much weaker answer to "why does this exist".

Recommendation: do not delete it. Write it. Prana is the obvious candidate for the resource that powers abilities, gates the barrier system, and gives the mythology mechanical teeth. It needs its own design document before anything else in the GDD is expanded.

C-04 — CRITICAL — Netcode choice vs. Battle Royale vs. "Fair gameplay"

Tech Arch: "Unity Netcode + Unity Gaming Services"
Bible → Pillars: "Fair gameplay"; Bible #1: "Performance First"; low-end Android
Nowhere: the number of players in a match.

Three compounding problems:

No player count is specified anywhere. A 100-player BR, a 60-player BR and a 30-player BR are three completely different engineering projects with different netcode, different map sizes, different server costs and different asset budgets. Nothing downstream can be estimated without this number.
Netcode for GameObjects (NGO) is a poor fit for large-scale BR. Its standard topology is client-hosted / distributed-authority over Relay. A phone acting as host for a large BR match is a performance problem and a fairness problem — the host has zero latency and can be tampered with. That directly contradicts "Fair gameplay". Realistic paths are dedicated server-authoritative hosting (UGS Game Server Hosting / Multiplay), or a different netcode stack (Netcode for Entities/DOTS, or Photon Fusion/Quantum). No dedicated-server line item appears in any document, and that is where the majority of the recurring cost of this game sits.
No anti-cheat is named at all. On Android, APK tampering and memory editing are trivial and endemic in the BR category. "Fair gameplay" as a pillar with no anti-cheat plan is an unsupported claim.

Recommendation: treat netcode as a Phase 0 gate, not a Phase 2 detail. Fix the player count first; then re-derive the netcode decision from it; then price dedicated servers before committing to the count. Server cost per CCU is the number that decides whether this game is viable at all.

C-05 — HIGH — Performance rules exist; performance budgets do not

Bible #1: "Performance First"
Tech Arch: "60 FPS target / 30 FPS minimum", "Mobile First", "Object Pooling", "Addressables", "Shared Skeleton"
ProjectOS brief: every asset must carry "Texture Budget", "Polygon Budget", "LOD Status"

The Tech Architecture lists techniques, not budgets. There is no device tier matrix, no target device, no draw-call ceiling, no triangle ceiling, no texture memory ceiling, no thermal/sustained-framerate policy, no APK/OBB size ceiling.

You cannot assign a per-asset polygon budget in ProjectOS when no global budget exists to divide up. The Asset Manager is architecturally blocked on this document.

Recommendation: write 05_ASTRA_Performance_Budget.md and treat it as locked and versioned. It must name a specific worst-case device (e.g. Snapdragon 4-series / 3 GB RAM class), and from it derive: max triangles on screen, max draw calls, max simultaneous skinned meshes, texture memory ceiling, per-character and per-weapon poly budgets, and a download-size ceiling. Everything in the Asset Manager then references this document by ID.

C-06 — HIGH — "Audio Before Graphics" is a hard rule that the pipeline does not obey

Bible #4: "Audio Before Graphics"
Production Bible: Phase 0 = "Game Design"; pipelines listed as Characters, Weapons, Maps, Audio (4th), QA, Releases
Nowhere: any audio specification, style guide, or deliverable.

The rule says audio leads. The production plan lists audio fourth and gives it no Phase 0 deliverable. The rule is currently decorative.

Recommendation: either give audio a Phase 0 deliverable (weapon audio set + hit/kill feedback before any weapon art), or amend the rule. My strong preference is the former — for a shooter it is genuinely correct, and it is cheap to honour early.

C-07 — HIGH — Silhouette rule vs. asset-reuse rule

Bible #3: "Silhouette First"; #9: "Recognition in one second"
Bible #2: "Reusable Assets"; Tech Arch: "Shared Skeleton", "Modular Assets"

These pull in opposite directions. A shared skeleton with modular parts is exactly the pipeline that produces five characters who read as the same shape at 40 metres on a 6-inch screen. The rules are both correct and both necessary; the reconciliation is missing.

Recommendation: add a rule: "Silhouette differentiation is achieved by non-skeletal attachments (headgear, back, shoulder, weapon carry pose) within a fixed poly allowance; the skeleton and base body stay shared." Then add a Silhouette Test protocol — black-fill the model, view at target screen size and distance, must be identified in one second by someone who has not seen it. That makes #3 and #9 testable rather than aspirational, which is the whole point of a hard rule.

C-08 — HIGH — Deployment target is occupied by a live system

Your brief: "Deploy it to https://invert.aurionglobal.my … The current trading project is paused. Archive it."
Verified today (2026-08-01): invert.aurionglobal.my/ → HTTP 302 (live, redirecting). invert.aurionglobal.my/legacy/ → HTTP 200 (live).

That domain currently serves the 5th Element / Samudra supervised swing pilot, with the older Inverse shadow book preserved at /legacy/. It is a running service (its own container and DB schema) that reads live tables and is driven by cron. "The current trading project is paused" is ambiguous here — the Aurion estate runs several books, and Invert is a shadow book that is not obviously the one you mean by "the trading project".

Taking that hostname's root for ProjectOS would replace a live pilot's front door. That is reversible but disruptive, and it is exactly the kind of thing that should not be assumed.

Recommendation: deploy ProjectOS to a new hostname — astra.aurionglobal.my — and leave Invert/Samudra untouched. It costs one Caddy block. If you specifically want ASTRA at invert., say so explicitly and I will move Samudra to its own hostname first and preserve /legacy/.

C-09 — HIGH — ProjectOS stack vs. "single source of truth"

Your brief → Tech stack: "Supabase, PostgreSQL, Prisma"
Your brief → Project Rules: "Never duplicate information. Everything should reference a single source of truth."
Existing estate: Postgres on the Contabo VPS, FastAPI services behind aifh_caddy.

Introducing Supabase adds a second, externally-hosted database alongside the Postgres instance that already runs everything you own. That is a second source of truth, a second backup story, a second outage surface, and a monthly bill — inside a project whose first rule is "never duplicate information".

Recommendation: Next.js + TypeScript + Tailwind + shadcn/ui + Prisma → your existing Postgres, containerised and routed through aifh_caddy like every other Aurion service. You keep the recommended stack almost exactly; you drop only the hosted-Supabase dependency. Same developer experience, one database, no new vendor. If you want Supabase specifically for its auth and storage, that is a defensible reason — but it should be a stated decision, not a default.

C-10 — MEDIUM — Single-source-of-truth is already violated, at 87 lines

Bible → Pillars: "Solo + Duo launch" (a game mode decision, living in the Bible)
GDD → Systems: no mention of modes, team size, or squad play.

Match modes are game design and belong in the GDD. They are currently only in the Bible. With four documents and 87 lines you already have overlapping ownership — which is precisely the failure mode ProjectOS exists to prevent, and good evidence that the document ownership model needs to be defined before the documents grow.

Recommendation: assign each document a strict domain and an owner, and forbid cross-writing:

Bible — vision, hard rules, pillars. Amendable only by explicit versioned amendment.
GDD — all systems, modes, numbers, balance.
Tech Arch — engine, netcode, budgets, tooling.
Production Bible — phases, gates, pipelines, schedule.

C-11 — MEDIUM — Document metadata required by ProjectOS does not exist

ProjectOS brief → Module 2: documents must have "Version history, Status (Locked / Draft / Deprecated), Search, Cross references"
ProjectOS brief → Module 11: the Consistency Engine must detect "broken references" and "naming inconsistency"
Reality: the documents have no frontmatter, no IDs, no version, no status, no owner, and no reference syntax.

A Consistency Engine cannot detect a broken reference in a corpus that has no reference format. Module 11 is blocked on a documentation contract.

Recommendation: before ProjectOS ingests anything, define a Document & Entity ID contract — YAML frontmatter (id, version, status, owner, supersedes), a stable entity ID scheme (CHR-001 Hanuman, WPN-003, ZONE-007, RUNE-012, AST-…), and a wiki-style [CHR-001](/entity/CHR-001) cross-reference syntax. That single contract makes modules 2, 3, 10 and 11 buildable. Without it they are decorative.

C-12 — MEDIUM — Title and naming inconsistency

Bible H1: "ASTRA: KALYUG PROTOCOL"
All other documents: "ASTRA"
Your brief: "Project ASTRA: KALYUG PROTOCOL"

Trivial today, expensive in three years across a codebase, an APK bundle ID, a store listing and a trademark. Also: no naming convention exists for anything (assets, prefabs, branches, zones).

Recommendation: lock the full title in the Bible, lock a short code (ASTRA) for filenames/namespaces/bundle ID, and write a Naming Convention section into the Tech Architecture covering assets, prefabs, materials, animation clips, and git branches. Naming conventions are worth ~nothing on day one and enormous amounts on day 500.

C-13 — MEDIUM — "Season" exists in production tracking but not in the game

ProjectOS brief → Module 9: Milestone Tracker covers "Alpha, Beta, Release, Patch, Season"
Production Bible: Phases 0–3 only; no live-ops phase, no season, no patch cadence
GDD: no battle pass, no season, no meta loop
Bible #8: "Features must improve retention" — but no retention loop is defined anywhere.

You are asking ProjectOS to track seasons for a game that has no seasons designed and no post-launch phase planned. Meanwhile the one rule that mandates retention has nothing to point at.

Recommendation: add Phase 4 — Live Operations to the Production Bible, and add a Meta Loop section to the GDD (session → reward → reason to return). For a cosmetics-only BR the meta loop is the business model; it cannot be an afterthought.

C-14 — MEDIUM — Karma is undefined and sits directly on top of a hard rule

GDD → Systems: "Karma"
Bible #6: "Never Sell Competitive Advantage"

If Karma affects matchmaking, loot quality, rewards or combat, it becomes a progression axis and collides with C-01. If it is purely behavioural (reporting, sportsmanship, penalties for leaving), it is safe and valuable. Undefined, it will drift toward the unsafe reading, because that is the direction designers always drift.

Recommendation: define Karma as behavioural only, zero combat effect, zero loot effect — or rename it, because the word invites a power interpretation.

2. Risks that are not contradictions

These do not conflict with anything — they are simply absent, and they are the kind of absent that ends projects.

R-01 — CRITICAL — Cultural and regulatory risk on deity depiction

The five launch heroes are Hanuman, Ravana, Sita, Krishna and Arjuna, in a cosmetics-monetised game.

Three specific exposures, stated as business risk, not as opinion:

Monetising deities. Selling skins for Hanuman and Krishna is materially different from selling skins for an original character. The Indian market has an established history of complaints, legal notices, and platform takedowns of games depicting Hindu deities in combat.
Sita as a combatant. This carries meaningfully higher sensitivity than the other four and is the most likely single trigger for organised objection.
Ravana as playable. Playable-antagonist framing is usually fine and often popular, but it interacts with (1).

None of this makes the concept unviable — mythology-first is a genuinely strong position, and successful Indian-mythology titles exist. But shipping without a stated policy means discovering the boundary after the store listing, which is the most expensive possible time.

Recommendation: write a Cultural Design Policy into the Bible before any character art is commissioned: what may be depicted, what may be monetised, what is reframed as inspired-by rather than depicting (e.g. "Vanara warrior" rather than Hanuman himself), and a named external reviewer. Doing this in Phase 0 costs a week. Doing it after Alpha costs the character pipeline.

R-02 — CRITICAL — No backend, accounts, economy, telemetry or store

Nothing in the Tech Architecture covers player accounts, entitlements, IAP validation, the cosmetics store, matchmaking service, or telemetry. For a cosmetics-only game the store and entitlement system is the revenue system — it is not a footnote. UGS covers some of this; which parts, and what is custom, is unstated.

R-03 — CRITICAL — Scope vs. capacity is not addressed anywhere

Declared content: 5 heroes, 10 weapon families (with evolutions), 10 combat zones, relics, runes, barriers, plus full UI/VFX/audio. A conservative first-pass estimate is 2,000–4,000 unique assets, before LODs and variants. There is no team, no headcount, no budget, no schedule, and no dates in any document. The Production Bible has four phase names and nothing else.

This is not a reason to stop. It is a reason to write a capacity plan before committing to 10 zones, and it is the strongest argument for Rule #2 (Reusable Assets) being enforced ruthlessly by the ProjectOS Asset Manager — which is, I think, exactly why you want ProjectOS built first. That reasoning is sound.

R-04 — HIGH — No exit criteria on any phase

"Phase 1: Vertical Slice" is a name, not a gate. Without measurable exit criteria per phase, ProjectOS's "Completion %" is arithmetic on nothing.

R-05 — HIGH — Missing gameplay definitions the GDD needs before art starts

Not yet specified: player count, match length, TTK, circle/shrink rules, map size, inventory/backpack model, healing model, revive rules for Duo, weapon damage model, ammo types, recoil model, aim assist policy, respawn/spectate, ranked structure, ping/comms. Each of these is a fork that changes assets.

R-06 — MEDIUM — No edge-case policy

Absent: disconnection/reconnection, host migration, AFK, team-killing, region/latency policy, offline mode, low-storage devices, account recovery, refunds, underage/consent handling and privacy compliance (India DPDP Act and the Malaysian entity's obligations both apply).

R-07 — MEDIUM — Unity commercial terms

Unity's licensing and fee structure has changed materially and repeatedly in recent years. A multi-year mobile F2P project must record the exact terms it is committing to, and revisit them at each phase gate.

3. What is genuinely good here

Stated plainly, because an audit that only lists problems is a misleading document:

The eleven hard rules are excellent. "Silhouette First", "Audio Before Graphics", "Recognition in one second", "Never sell competitive advantage" — that is a disciplined, opinionated, shippable philosophy. Most projects at this stage have marketing adjectives instead. Keep all eleven; my recommendations amend how they are enforced, never what they say.
"Mythology inspires, not constrains" is the correct formulation and pre-solves much of R-01 — it just needs to be operationalised.
The instinct to build ProjectOS before the game is right. For a one-person-plus-AI team attempting AAA-scale content, the asset-duplication and consistency failure mode is the actual project killer. Building the control system first is the correct call.

4. Approval gate

Nothing has been changed, fixed, or implemented. No document was edited. No code was written. No infrastructure was touched.

I need decisions on the items in ACTION_REQUIRED_2026-08-01.md before implementation begins. The three that block ProjectOS specifically are C-08 (hostname), C-09 (stack/database), and C-11 (ID contract). The three that block the game are C-01 (progression), C-03 (Prana) and C-04 (player count/netcode) — but those do not block ProjectOS, and can be answered inside ProjectOS once it exists.