Inspiration
High-stakes proprietary systems often need to demonstrate specific facts without exposing their source code, internal data, credentials, infrastructure, or operational logic.
The problem is that ordinary dashboards can blur the distinction between evidence and claims. A positive-looking status may appear authoritative even when the underlying evidence is missing, ambiguous, expired, conflicting, or outside its permitted scope.
Darkmanus Evidence Console was built to solve that problem with a conservative rule: every supported claim must be tied to exact, owner-approved evidence, and anything that cannot be proven must fail closed.
What it does
Darkmanus Evidence Console is a separate, deterministic, read-only application. The proprietary Darkmanus platform remains completely outside the repository and deployed application.
The Console loads only an owner-approved, sanitized JSON evidence record from a fixed allowlisted repository path. It does not accept uploads, user-controlled paths, credentials, trading data, broker access, source code, network requests, execution commands, or model-generated runtime decisions.
Each evidence record passes a deterministic verification lifecycle:
- allowlist confirmation;
- raw-byte and SHA-256 integrity verification;
- UTF-8 and duplicate-key-safe JSON parsing;
- schema validation;
- owner-approval verification;
- policy-based evidence admission;
- evaluation against one precisely registered descriptive claim.
The public application demonstrates one limited supported result: the deterministic engine test suite passed, with 183 of 183 selected tests recorded as passed.
The Console also displays conservative outcomes for missing or inadmissible evidence and explicitly prohibits unsupported readiness claims involving profitability, demo readiness, live readiness, autonomous readiness, or institutional readiness.
How we built it
The project was implemented as an isolated Python repository with a strict trust boundary around a single sanitized evidence fixture.
Codex performed most of the repository implementation work, including:
- strict evidence and policy models;
- canonical integrity verification;
- evidence-admission logic;
- deterministic claim evaluation;
- a fixed-allowlist secure loader;
- fail-closed error handling;
- the immutable presentation layer;
- the read-only Streamlit interface;
- automated tests and Git preparation.
GPT-5.6 Thinking was used for:
- product definition;
- scope control;
- security and trust-boundary architecture;
- deterministic evidence and claim-policy design;
- prohibited-readiness guardrails;
- review orchestration;
- owner-approval workflows;
- Build Week and submission strategy.
Claude was used only as an owner-approved separate technical reviewer. It was not the primary builder, and its review was not presented as independent certification or an external audit.
The deployed runtime intentionally contains no LLM or model API. Development tools helped build and review the application, but deterministic repository code remains the final authority.
The project includes 244 automated tests and a fresh-install GitHub Actions matrix covering Ubuntu and Windows with Python 3.11.
A clean-history public repository was created so the submission could be inspected without exposing private development history or unrelated personal metadata.
Challenges we ran into
The main challenge was preserving strong evidence integrity while keeping the public application completely separated from the proprietary system.
This required careful handling of:
- exact raw fixture bytes across Windows and Linux checkouts;
- cryptographic hashes and canonical JSON digests;
- duplicate JSON keys;
- malformed or unsupported policy versions;
- missing, duplicated, expired, conflicting, or blocked evidence;
- accidental overstatement of what a verified record proves;
- public-release history and metadata hygiene;
- a usable interface that still fails closed.
A cross-platform CI failure revealed that Git line-ending conversion could change the approved fixture bytes on Windows. We fixed this with a narrowly scoped .gitattributes rule that preserves the evidence fixture with LF line endings while leaving the rest of the repository unchanged.
Accomplishments that we're proud of
We are proud that the Console:
- provides an exact, reproducible chain from approved evidence to a supported claim;
- preserves the approved evidence fixture byte-for-byte across supported platforms;
- returns conservative outcomes instead of optimistic defaults;
- makes prohibited readiness claims structurally incapable of becoming supported;
- exposes no proprietary strategies, trading data, credentials, broker access, infrastructure, or source code;
- passed 244 automated tests;
- passed fresh-install CI on Ubuntu and Windows with Python 3.11;
- is publicly testable without rebuilding;
- has a clean-history public repository with an MIT license;
- remains deterministic and read-only in production.
What we learned
The project reinforced that evidence systems should treat proof, claims, and presentation as separate layers.
A strong interface is not enough. Trust depends on exact evidence identity, reproducible integrity checks, explicit policy versions, narrow claim registration, predictable failure states, and transparent limitations.
We also learned that deployment and repository hygiene are part of the security model. Line endings, commit metadata, public history, documentation accuracy, and CI behavior can all affect whether a public verification system is trustworthy.
Most importantly, AI-assisted development does not require AI to remain in the runtime. GPT-5.6, Codex, and Claude accelerated design, implementation, and review, while the final application deliberately relies on deterministic code.
What's next for Darkmanus Evidence Console
The next steps are to expand the Console without weakening its trust boundaries.
Possible future work includes:
- additional owner-approved evidence records;
- more registered descriptive claims;
- signed evidence manifests;
- stronger provenance and approval workflows;
- machine-readable verification reports;
- exportable evidence summaries;
- additional deterministic policy tests;
- accessibility and interface refinements;
- deployment monitoring that remains separate from the protected proprietary platform.
Any expansion will preserve the core rule: no claim becomes supported unless the exact required evidence is valid, admitted, current, unambiguous, and sufficient.
Log in or sign up for Devpost to join the conversation.